如何验证资源服务器的OAuth 2.0访问令牌?


147

当客户端要求资源服务器获取带有OAuth 2.0访问令牌的受保护资源时,该服务器如何验证令牌?OAuth 2.0刷新令牌协议?


该服务器应该能够验证其先前已发行的令牌...通常,这将是数据库查找或加密(自签名令牌)。
Thilo 2012年

我懂了。在这种情况下,资源所有者WS和客户端WS都在不同的设备上怎么样?
2012年

5
您是指认证服务和资源服务?(客户端/消费者将始终在不同的设备上,并且无法亲自验证令牌)。在这种情况下,您可以使用“昂贵”的刷新令牌进行检查(只有身份验证服务器可以这样做),但使用寿命长且访问令牌,这些令牌经常过期并且可以脱机检查。
Thilo 2012年

Answers:


97

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的非常补充。


Scott T,有没有办法查看有关如何使用Ping Federate中的功能的代码示例?
JavaHead

2
@JavaHead在我们的开发人员网站上有更多协议详细信息,网址为:developer.pingidentity.com/en/resources / ...,PingFederate OAuth Playground作为一组JSP发行,可以用作验证令牌的源代码。可以从这里下载它(以及其他开源库和示例):developer.pingidentity.com/en/code.html
Scott T.

斯科特,我正在寻找一个示例,该示例将演示具有Rest API的客户端凭据授予,并由本地资源服务器和PingFederate作为Auth服务器保护。然后,本地资源服务器将调用验证端点。你有没有遇到过这样的事情?
JavaHead

再次使用@JavaHead,您应该可以引用PingFederate OAuth Playground。它演示了客户端凭据授予类型和资源服务器对访问令牌的验证。
Scott T.

对于JWT访问令牌,我假设您通常不希望对RS的每个传入请求都打入AS自省端点。在那种情况下,对令牌签名和范围进行RS检查是否足够?或者,也许RS可以缓存来自AS的自省响应一段时间?
加里(Gary)19年

119

谷歌方式

Google Oauth2令牌验证

请求:

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
} 

微软方式

Microsoft-Oauth2检查授权

Github方式

Github-Oauth2检查授权

请求:

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
}

2
@gustavodiazjaimes根本没有解释服务器端如何从令牌中识别分配的用户ID。
user2284570

22
我不明白所有的赞成票。这似乎无法回答问题。
邓肯·琼斯

有人知道Azure Active Directory是否具有类似的终结点来检查颁发的令牌是否有效吗?
user180940 '18

2
换句话说,自己动手。
AndroidDev '18

51

@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"
}

当然,供应商和产品的采用必须随着时间的流逝而发生。


如果使用OoenId连接难道我们不应该更喜欢使用ID令牌来验证访问的OpenID的方式标记:openid.net/specs/...
阿德南kamili

1
@Renan:与授权请求中请求范围的方式保持一致,该请求带有一个scope查询参数,其值包含以空格分隔的范围列表
HansZ。17年

4
如果理事机构尚未正式接受某些内容,请不要使用“标准化”一词。截至2018年2月的IETF RFC 7662明确表明它是“提案”。
AndroidDev '18

1
@adnankamili没有“建议”之类的东西。到文档成为RFC时,它已经是“提议的标准”,在其后面具有重要的意义。OAuth 2.0本身仍然是“提议的标准”,因此我不确定您要提出什么观点。
佩斯

15

OAuth 2.0规范未定义该部分。但是可能有几种选择:

  1. 当资源服务器在Authz标头中获取令牌时,它将调用Authz服务器上的validate / introspect API来验证令牌。在这里,Authz服务器可以通过使用数据库存储或验证签名和某些属性来对其进行验证。作为响应的一部分,它解码令牌并发送令牌的实际数据以及剩余的到期时间。

  2. Authz Server可以使用私钥对令牌进行加密/签名,然后可以将Publickey / cert提供给Resource Server。当资源服务器获取令牌时,它要么解密/验证签名以验证令牌。取出内容并处理令牌。然后,它可以提供访问或拒绝。


8

OAuth v2规范表明:

访问令牌属性和用于访问受保护资源的方法超出了本规范的范围,并由随附规范定义。

我的授权服务器具有一个Web服务(SOAP)端点,该端点使资源服务器可以知道access_token是否有效。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.