我目前使用的是"lucadegasperi/oauth2-server-laravel"。
我正在为第三方可信客户端创建一个api端点，并使用client_credentials授予。
现在的问题是，访问令牌往往会过期，所以，而不是给第三方用户一个访问令牌，我将只提供给他们客户端id/secret。
在我这边，当他们做curl请求时，我会做以下操作…
SELECT a.id,
expire_time
FROM oauth_clients as c
left join oauth_sessions as s on s.client_id = c.id
left join oauth_access_tokens as a on a.session_id = s.id
where c.id = 'asfasasf'
and c.secret = 'asfasfasfasf'
order by s.id desc
limit 1;
…上面的代码检查了是否存在与客户端id/secret相关的访问令牌和过期时间。如果一个不存在或者过期了，我就会生成一个新的。然后再下几行，在我这边使用给定的access_token对他们所追求的端点进行卷曲，而不用担心这样做。
我已经测试过了，它可以工作，但这是一种狡猾/不好做吗?
tldr;
- 第三方客户端-到/api/端点，客户端id/secret
- 我的服务器端(检查db中与客户端id/secret相关的访问令牌)
- 生成如果不存在或过期使用…
- 第三方客户端端点api继续使用db选择的访问令牌
这个流不好吗?
你所做的一切都是为了方便他们。
很多人会简单地使用他们或别人写的OAuth2库，当然这是行不通的，因为你不再有一个标准的OAuth2系统了。
你已经有效地为使用客户端应用程序的每个人重用了一个令牌，我不相信这是一件好事。令牌过期是为了安全问题，如果有人偷了一个令牌，你可以使它无效并阻止他们访问，或者它过期，就是这样。当然，您不会遇到这个问题，因为您实际上并没有传递令牌。
这也意味着你现在正在破坏其他OAuth2流，许多系统都有刷新令牌，这也消失了。我想它简化了客户的生活，但你不能说你有一个OAuth2系统了，因为你没有。
客户端是需要处理令牌的人，他们的工作是决定如何存储它们以及当事情到期时该怎么做。您通常不需要担心这个问题，但现在您需要担心了，因为实际上您将客户机令牌存储在您这边。
另一件需要考虑的事情是，你把安全问题转移到了你这边。你现在要对客户的安全负责。如果有人访问了您的数据库，那么他们很可能在您或客户都不知道的情况下，永远有效地冒充您的所有客户。从我的角度来看，在数据库中使用令牌是一个坏主意，也是一个安全漏洞，特别是当客户端无法控制它时。
所以我想我应该这样做:
- 将向最终消费者提供客户端id和secret。
- 由于最终用户是基于可信客户端机器的，因此他们将使用客户端凭据授予，并且只检索访问令牌。
- 终端消费者可以简单地卷曲并检索访问令牌，然后使用生成的访问令牌在前一个卷曲下进行另一个卷曲。
- 使用访问令牌的最后一个curl将能够访问受保护的资源。