OAuth 2.0承载令牌到底是什么? [英] What is the OAuth 2.0 Bearer Token exactly?

问题描述

根据 RFC6750 -OAuth 2.0授权框架:承载令牌用法，承载令牌为:

具有令牌的任何一方(承载者")可以以任何其他任何拥有它的方可以使用的方式使用令牌的属性的安全令牌.

对我来说，这个定义是模糊的，我找不到任何规范.

• 假设我正在实现授权提供者，我可以为承载令牌提供任何类型的字符串吗?
• 可以是随机字符串吗?
• 是否必须是某些属性的base64编码?
  应该对其进行哈希处理吗?
• 服务提供商是否需要查询授权提供商以验证此令牌?

谢谢您的指点.

解决方案

承载者令牌
具有任何一方拥有的财产的安全令牌令牌(承载者")可以以任何其他方式使用令牌拥有它的一方可以.使用不记名令牌要求持证人证明拥有加密密钥材料(所有权证明).

承载令牌是由身份验证服务器创建的.当用户对您的应用程序(客户端)进行身份验证时，身份验证服务器将为您生成令牌.承载令牌是OAuth 2.0使用的主要访问令牌类型.Bearer令牌基本上说给此令牌访问的载体".

承载令牌通常是身份验证服务器创建的某种不透明值.它不是随机的；它不是随机的.它是根据用户授予您访问权限的情况以及客户端您的应用程序获得访问权限的情况创建的.

例如，要访问API，您需要使用访问令牌.访问令牌是短暂的(大约一个小时).您可以使用承载令牌来获取新的访问令牌.要获取访问令牌，您需要将此身份验证令牌和客户端ID一起发送给身份验证服务器.这样，服务器知道使用承载令牌的应用程序与为其创建承载令牌的应用程序相同.示例:我不能只接受为您的应用程序创建的承载令牌，然后将其与我的应用程序一起使用，因为它不是为我生成的，因此无法使用.

Google Refresh令牌看起来像这样:1/mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM

从评论中复制:我认为您提供的不记名令牌没有任何限制.我唯一能想到的就是允许多于一个.例如，用户最多可以对应用程序进行30次身份验证，并且旧的承载令牌仍将起作用.哦，如果有6个月没有使用过，那么我将从您的系统中删除它.身份验证服务器将必须生成它们并对其进行验证，以便它的格式由您决定.

更新:

在每个内联操作" HTTP请求的授权"标头中设置了一个承载令牌.例如:

  POST/rsvp?eventId = 123 HTTP/1.1主持人:events-organizer.com授权:Bearer AbCdEf123456内容类型:application/x-www-form-urlencoded用户代理:Mozilla/5.0(X11; Linux x86_64)AppleWebKit/1.0(KHTML，例如Gecko； Gmail Actions)rsvpStatus =是 

上例中的字符串"AbCdEf123456" 是承载授权令牌.这是认证服务器生成的加密令牌.随操作发送的所有承载令牌都有问题字段，而受众字段将发件人域指定为https://形式的URL.例如，如果电子邮件来自[e-mail]，则受众为 https://example.com .

如果使用承载令牌，请验证该请求是否来自身份验证服务器，并且是否针对发件人域.如果令牌未验证，则服务应使用HTTP响应代码401(未授权)来响应请求.

承载者令牌是OAuth V2标准的一部分，并被许多API广泛采用.

According to RFC6750-The OAuth 2.0 Authorization Framework: Bearer Token Usage, the bearer token is:

A security token with the property that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can.

To me this definition is vague and I can't find any specification.

• Suppose I am implementing an authorization provider, can I supply any kind of string for the bearer token?
• Can it be a random string?
• Does it have to be a base64 encoding of some attributes?
  Should it be hashed?
• And does the service provider need to query the authorization provider in order to validate this token?

Thank you for any pointer.

解决方案

Bearer Token
A security token with the property that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession).

The Bearer Token is created for you by the Authentication server. When a user authenticates your application (client) the authentication server then goes and generates for you a Token. Bearer Tokens are the predominant type of access token used with OAuth 2.0. A Bearer token basically says "Give the bearer of this token access".

The Bearer Token is normally some kind of opaque value created by the authentication server. It isn't random; it is created based upon the user giving you access and the client your application getting access.

In order to access an API for example you need to use an Access Token. Access tokens are short lived (around an hour). You use the bearer token to get a new Access token. To get an access token you send the Authentication server this bearer token along with your client id. This way the server knows that the application using the bearer token is the same application that the bearer token was created for. Example: I can't just take a bearer token created for your application and use it with my application it wont work because it wasn't generated for me.

Google Refresh token looks something like this: 1/mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM

copied from comment: I don't think there are any restrictions on the bearer tokens you supply. Only thing I can think of is that its nice to allow more than one. For example a user can authenticate the application up to 30 times and the old bearer tokens will still work. oh and if one hasn't been used for say 6 months I would remove it from your system. It's your authentication server that will have to generate them and validate them so how it's formatted is up to you.

Update:

A Bearer Token is set in the Authorization header of every Inline Action HTTP Request. For example:

POST /rsvp?eventId=123 HTTP/1.1
Host: events-organizer.com
Authorization: Bearer AbCdEf123456
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)

rsvpStatus=YES

The string "AbCdEf123456" in the example above is the bearer authorization token. This is a cryptographic token produced by the authentication server. All bearer tokens sent with actions have the issue field, with the audience field specifying the sender domain as a URL of the form https://. For example, if the email is from [e-mail], the audience is https://example.com.

If using bearer tokens, verify that the request is coming from the authentication server and is intended for the the sender domain. If the token doesn't verify, the service should respond to the request with an HTTP response code 401 (Unauthorized).

Bearer Tokens are part of the OAuth V2 standard and widely adopted by many APIs.

这篇关于OAuth 2.0承载令牌到底是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！