当客户端要求资源服务器获取带有OAuth 2.0访问令牌的受保护资源时,该服务器如何验证令牌?OAuth 2.0刷新令牌协议?
当客户端要求资源服务器获取带有OAuth 2.0访问令牌的受保护资源时,该服务器如何验证令牌?OAuth 2.0刷新令牌协议?
Answers:
2015年11月更新:根据下方的Hans Z.,现在确实已将其定义为RFC 7662的一部分。
原始答案: OAuth 2.0规范(RFC 6749)并未明确定义资源服务器(RS)和授权服务器(AS)之间的交互,以进行访问令牌(AT)验证。这实际上取决于AS的令牌格式/策略-有些令牌是自包含的(例如JSON Web令牌),而另一些令牌可能类似于会话cookie,因为它们仅引用AS保留在服务器端的信息。
OAuth工作组中已有一些讨论,涉及为RS与AS进行通信以进行AT验证创建标准方法。我的公司(Ping Identity)为我们的商业OAuth AS(PingFederate)提出了一种这样的方法:https : //support.pingidentity.com/s/document-item? bundleId = pingfederate-93 & topicId = lzn1564003025072.html#lzn1564003025072__section_N10578_N1002A_N10001 。为此,它使用基于REST的交互,这是对OAuth 2.0的非常补充。
请求:
https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg
响应:
{
"audience":"8819981768.apps.googleusercontent.com",
"user_id":"123456789",
"scope":"https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
"expires_in":436
}
请求:
GET /applications/:client_id/tokens/:access_token
响应:
{
"id": 1,
"url": "https://api.github.com/authorizations/1",
"scopes": [
"public_repo"
],
"token": "abc123",
"app": {
"url": "http://my-github-app.com",
"name": "my github app",
"client_id": "abcde12345fghij67890"
},
"note": "optional note",
"note_url": "http://optional/note/url",
"updated_at": "2011-09-06T20:39:23Z",
"created_at": "2011-09-06T17:26:27Z",
"user": {
"login": "octocat",
"id": 1,
"avatar_url": "https://github.com/images/error/octocat_happy.gif",
"gravatar_id": "somehexcode",
"url": "https://api.github.com/users/octocat"
}
}
使用Amazon登录-开发人员指南(2015年12月,第21页)
要求:
https://api.amazon.com/auth/O2/tokeninfo?access_token=Atza|IQEBLjAsAhRmHjNgHpi0U-Dme37rR6CuUpSR...
回应:
HTTP/l.l 200 OK
Date: Fri, 3l May 20l3 23:22:l0 GMT
x-amzn-RequestId: eb5be423-ca48-lle2-84ad-5775f45l4b09
Content-Type: application/json
Content-Length: 247
{
"iss":"https://www.amazon.com",
"user_id": "amznl.account.K2LI23KL2LK2",
"aud": "amznl.oa2-client.ASFWDFBRN",
"app_id": "amznl.application.436457DFHDH",
"exp": 3597,
"iat": l3ll280970
}
@Scott T.的答案的更新:用于令牌验证的资源服务器和授权服务器之间的接口已在2015年10月的IETF RFC 7662中标准化,请参阅:https : //tools.ietf.org/html/rfc7662。验证调用示例如下所示:
POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer 23410913-abewfq.123483
token=2YotnFZFEjr1zCsicMWpAA
以及示例响应:
HTTP/1.1 200 OK
Content-Type: application/json
{
"active": true,
"client_id": "l238j323ds-23ij4",
"username": "jdoe",
"scope": "read write dolphin",
"sub": "Z5O3upPC88QrAjx00dis",
"aud": "https://protected.example.net/resource",
"iss": "https://server.example.com/",
"exp": 1419356238,
"iat": 1419350238,
"extension_field": "twenty-seven"
}
当然,供应商和产品的采用必须随着时间的流逝而发生。
scope
查询参数,其值包含以空格分隔的范围列表
OAuth 2.0规范未定义该部分。但是可能有几种选择:
当资源服务器在Authz标头中获取令牌时,它将调用Authz服务器上的validate / introspect API来验证令牌。在这里,Authz服务器可以通过使用数据库存储或验证签名和某些属性来对其进行验证。作为响应的一部分,它解码令牌并发送令牌的实际数据以及剩余的到期时间。
Authz Server可以使用私钥对令牌进行加密/签名,然后可以将Publickey / cert提供给Resource Server。当资源服务器获取令牌时,它要么解密/验证签名以验证令牌。取出内容并处理令牌。然后,它可以提供访问或拒绝。