oauth2 由提供的客户端 id/secret 通过数据库为受信任的第 3 方客户端获取访问令牌
oauth2 get access token via db by supplied client id/secret for trusted 3rd party client
我目前正在使用 "lucadegasperi/oauth2-server-laravel"。
我正在为第 3 方可信客户端创建一个 api 端点并使用 client_credentials 授权。
现在的问题是访问令牌往往会过期，所以我不会给第 3 方用户一个访问令牌，而只是向他们提供客户端 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 之后的终点，而不用他们担心这样做。
我已经测试过它并且有效，但是这种 dodgy/bad 可以吗？
tldr;
- 第 3 方客户 - 与客户 id/secret
一起前往 /api/endpoint
- 我的服务器端（检查数据库中与客户端相关的访问令牌 id/secret）
- 如果不存在或已过期无法使用则生成...
- 第 3 方客户端端点 api 继续使用数据库选择的访问令牌
- 有效
流量不好吗？
为了他们的方便，您只是走了一步。
很多人会简单地使用他们或其他人编写的 OAuth2 库，当然这行不通，因为您不再有标准的 OAuth2 系统。
您已经为使用客户端应用程序的其他所有人有效地重复使用了一个令牌，我认为这不是一件好事。令牌过期是为了安全问题，如果有人窃取了令牌，您可以使它无效并停止他们的访问，或者它会过期，仅此而已。当然你没有这个问题，因为你实际上并没有传递令牌。
这也意味着您现在正在破坏其他 OAuth2 流程，许多系统都有一个刷新令牌，它也消失了。我猜它大大简化了客户的生活，但你不能再说你有 OAuth2 系统了，因为你没有。
客户是需要处理代币的人，他们的工作是决定如何存储代币以及当代币过期时要做什么。您通常不需要担心它，但现在您需要担心，因为您实际上将客户端令牌存储在您身边。
另一件需要考虑的事情是，您将安全问题转移到了自己这边。您现在负责客户的安全。如果有人可以访问您的数据库，那么他们很可能永远有效地冒充您的所有客户，甚至您或客户都不知道。从我的角度来看，在数据库中拥有令牌是一个坏主意，也是一个安全漏洞，尤其是当客户端无法控制它时。
所以我想我会选择以下内容：
- 最终消费者将获得客户端 ID 和密码。
- 由于最终用户是基于受信任的客户端计算机，他们将使用客户端凭据授权并且仅检索访问令牌。
- 最终消费者可以简单地 curl 并检索访问令牌，然后使用生成的访问令牌在前一个 curl 的下方进行另一个 curl。
- 最后一次使用访问令牌的 curl 将能够访问受保护的资源。
我目前正在使用 "lucadegasperi/oauth2-server-laravel"。
我正在为第 3 方可信客户端创建一个 api 端点并使用 client_credentials 授权。
现在的问题是访问令牌往往会过期，所以我不会给第 3 方用户一个访问令牌，而只是向他们提供客户端 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 之后的终点，而不用他们担心这样做。
我已经测试过它并且有效，但是这种 dodgy/bad 可以吗？
tldr;
- 第 3 方客户 - 与客户 id/secret 一起前往 /api/endpoint
- 我的服务器端（检查数据库中与客户端相关的访问令牌 id/secret）
- 如果不存在或已过期无法使用则生成...
- 第 3 方客户端端点 api 继续使用数据库选择的访问令牌
- 有效
流量不好吗？
为了他们的方便，您只是走了一步。
很多人会简单地使用他们或其他人编写的 OAuth2 库，当然这行不通，因为您不再有标准的 OAuth2 系统。
您已经为使用客户端应用程序的其他所有人有效地重复使用了一个令牌，我认为这不是一件好事。令牌过期是为了安全问题，如果有人窃取了令牌，您可以使它无效并停止他们的访问，或者它会过期，仅此而已。当然你没有这个问题，因为你实际上并没有传递令牌。
这也意味着您现在正在破坏其他 OAuth2 流程，许多系统都有一个刷新令牌，它也消失了。我猜它大大简化了客户的生活，但你不能再说你有 OAuth2 系统了，因为你没有。
客户是需要处理代币的人，他们的工作是决定如何存储代币以及当代币过期时要做什么。您通常不需要担心它，但现在您需要担心，因为您实际上将客户端令牌存储在您身边。
另一件需要考虑的事情是，您将安全问题转移到了自己这边。您现在负责客户的安全。如果有人可以访问您的数据库，那么他们很可能永远有效地冒充您的所有客户，甚至您或客户都不知道。从我的角度来看，在数据库中拥有令牌是一个坏主意，也是一个安全漏洞，尤其是当客户端无法控制它时。
所以我想我会选择以下内容：
- 最终消费者将获得客户端 ID 和密码。
- 由于最终用户是基于受信任的客户端计算机，他们将使用客户端凭据授权并且仅检索访问令牌。
- 最终消费者可以简单地 curl 并检索访问令牌，然后使用生成的访问令牌在前一个 curl 的下方进行另一个 curl。
- 最后一次使用访问令牌的 curl 将能够访问受保护的资源。