2-legged oauth 如何在 OAuth 2.0 中工作? [英] How does 2-legged oauth work in OAuth 2.0?

问题描述

在 OAuth 1.0 中，2-legged 非常容易:只需像往常一样发送请求并省略 access_token 标头.

In OAuth 1.0, 2-legged is pretty easily: Simply send the request as usual and omit the access_token header.

事情似乎在 OAuth 2.0 中发生了变化(正如我今天发现的那样:)).在 OAuth 2.0 中，请求不再具有诸如随机数、消费者密钥、时间戳等标头.这只是替换为:

Things seems to have changed in OAuth 2.0 (drastically, as I found out today :)). In OAuth 2.0, the request no longer has headers such as the nonce, consumer key, timestamp etc. This is just replaced by:

Authorization: OAuth ya29.4fgasdfafasdfdsaf3waffghfhfgh

我了解 OAuth 2.0 和应用流程中的 3 条腿授权是如何工作的.但是 2-legged 在 2.0 中是如何工作的呢?有没有可能设计一个可以同时支持 2-legged 和 3-legged OAuth 2.0 的 API?

I understand how 3 legged authorizations work in OAuth 2.0 and the application flows. But how does 2-legged work in 2.0? Is it possible to design an API that can support both 2-legged and 3-legged OAuth 2.0?

我一直在寻找有关这方面的信息，但是我在 1.0 的 2-legged 上找到了很多东西，而对于 2.0 几乎没有.

I have been searching for information regarding this, but I have been finding a lot of stuff on 2-legged for 1.0 and almost nothing for 2.0.

推荐答案

经过大量研究，我发现 client_credentials 授予类型适用于这种情况.一旦你把这个词打进谷歌，你会发现很多非常有用的资源.

After lots of research, I discovered that client_credentials grant type is for this scenario. Once you punch this term into google, you can find loads of very helpful resources.

这是 3-legged OAuth 2.0 的正常流程(我们希望用户登录):

This is the normal flow for 3-legged OAuth 2.0 (we want the user to sign in):

假设我们的应用中有以下用于身份验证的端点:

Assume we have the following endpoints in our app for authentication:

/oauth/auth

/oauth/token

通常(对于授权代码授予)，我们会将用户定向到 /oauth/auth?state=blah&client_id=myid&redirecturl=mysite.com/blah

Normally (for authorization code grant), we direct the user to /oauth/auth?state=blah&client_id=myid&redirecturl=mysite.com/blah

然后在身份验证后，用户被重定向到 mysite.com/blah?code=somecode

Then upon authentication, the user is redirected to mysite.com/blah?code=somecode

然后我们得到 somecode 并使用 /oauth/token?code=somecode&client_id=myid&client_secret=mysecret

We then get somecode and exchange it for a token using /oauth/token?code=somecode&client_id=myid&client_secret=mysecret

然后我们可以使用令牌拨打电话.

We can then use the token to make calls.

这是 client_credentials 实现 2-legged OAuth 2.0 的应用流程，明显更简单:

This is the application flow for client_credentials to implement 2-legged OAuth 2.0, which is markedly simplier:

• 在这种方法中，我们不需要执行任何身份验证.

• 我们只需使用以下表单数据 POST 到 /oauth/token:

grant_type=client_credentials&scope=view_friends

请注意，范围是可选的.然后端点直接返回一个访问令牌供我们使用(不提供刷新令牌).由于没有提供刷新令牌，当令牌过期时，您将需要重新进行身份验证并请求一个新的.

Note that scope is optional. The endpoint then directly returns an access token for us to use (no refresh token is provided). Since no refresh token is provided, when the token expires, you will need to reauthenticate and ask for a new one.

这会导致以下警告:

• 仅将此用于(非常)受信任的应用程序，例如内部应用程序.
• 您需要设计自己的身份验证方式.例如，RFC 的示例 使用基本身份验证.

• Use this only for (very very) trusted applications such as internal applications.
• You need to devise your own way to authenticate. For instance, the RFC's example uses basic auth.

另一种解决方案是使用 JWT(JSON 网络令牌)，例如 google OAuth API.这是一个非常复杂的过程，但有许多库可用于生成 JWT.然后您发布以下表单数据(当然是 url 编码):

Another solution is to use JWT (JSON web tokens) like the google OAuth API. It is a very complicated process, but there exists numerous libraries for generating your JWT. You then post the following form data (url encoded of course):

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=generated_jwt

这会发布到 /oauth/token 以获取您的令牌.

This is posted to /oauth/token to get your token.

至于是否可以创建支持 2-legged 和 3-legged OAuth 2.0 的 API 的问题，可以.

然后 /auth 端点仅在用户需要对服务进行身份验证时使用.

Then /auth endpoint is only used when users need to authenticate against the service.

在 /token 端点中，只需检查 urn:ietf:params:oauth:grant-type:jwt 的 GET 参数中 grant_type 的值-bearer 如果使用 JWT 或 client_credentials 作为 client_credentials.

In the /token endpoint, simply check the value of grant_type in the GET parameters for urn:ietf:params:oauth:grant-type:jwt-bearer if using JWT or client_credentials for client_credentials.

请注意，在生成要提供给用户的 client_id 和 client_secret 时，如果您支持多个 grant_types，请确保您有一个数据库列来存储 id 和机密是什么类型的授权类型为.如果需要为每个用户提供多种授权类型，请为每种授权类型生成一组不同的凭据.

Note that when generating the client_id and client_secret to give to the user, if you are supporting multiple grant_types, ensure that you have a database column to store what type of grant type the id and secret was generated for. If required to have multiple grant types per user, generate a different set of credentials for each grant type.

这篇关于2-legged oauth 如何在 OAuth 2.0 中工作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！