经过大量研究,我发现client_credentials
授予类型适用于这种情况。一旦你把这个词打进谷歌,你会发现很多非常有用的资源。
这是 3-legged OAuth 2.0 的正常流程(我们希望用户登录):
假设我们的应用中有以下端点用于身份验证:
/oauth/auth
/oauth/token
通常(对于授权码授予),我们指导用户/oauth/auth?state=blah&client_id=myid&redirecturl=mysite.com/blah
然后在认证后,用户被重定向到mysite.com/blah?code=somecode
然后我们somecode
使用/oauth/token?code=somecode&client_id=myid&client_secret=mysecret
然后我们可以使用令牌进行调用。
这是client_credentials
实现 2-legged OAuth 2.0 的应用程序流程,它明显更简单:
请注意,范围是可选的。然后端点直接返回一个访问令牌供我们使用(不提供刷新令牌)。由于没有提供刷新令牌,因此当令牌过期时,您将需要重新进行身份验证并请求一个新令牌。
这导致以下警告:
- 仅将其用于(非常非常)受信任的应用程序,例如内部应用程序。
- 您需要设计自己的身份验证方式。例如,RFC 的示例使用基本身份验证。
另一种解决方案是使用 JWT(JSON Web 令牌),例如google OAuth API。这是一个非常复杂的过程,但是存在许多用于生成 JWT 的库。然后,您发布以下表单数据(当然是 url 编码):
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=generated_jwt
这是/oauth/token
为了获取您的令牌而发布的。
至于是否可以创建支持 2-legged 和 3-legged OAuth 2.0 的 API的问题,是的,可以。
然后/auth
端点仅在用户需要对服务进行身份验证时使用。
在/token
端点中,只需检查grant_type
GET 参数中的值urn:ietf:params:oauth:grant-type:jwt-bearer
是否使用 JWT 或client_credentials
client_credentials。
请注意,在生成 client_id 和 client_secret 以提供给用户时,如果您支持 multiple grant_types
,请确保您有一个数据库列来存储生成 id 和 secret 的授权类型。如果需要为每个用户提供多种授权类型,请为每种授权类型生成一组不同的凭据。