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

当客户端请求资源服务器使用OAuth 2.0访问令牌获取受保护资源时,此服务器如何validation令牌? OAuth 2.0刷新令牌协议?

OAuth 2.0规范没有明确定义资源服务器(RS)和授权服务器(AS)之间的访问令牌(AT)validation的交互。 它实际上取决于AS的令牌格式/策略 – 一些令牌是独立的(比如JSON Web Tokens ),而另一些可能类似于会话cookie,因为它们只是在内存中引用AS的信息。

OAuth工作组已经就一些 RS与AS进行通信的标准方法进行了讨论 ,以进行ATvalidation。 我的公司(Ping Identity)为我们的商业OAuth AS(PingFederate)提出了一个这样的方法: https ://documentation.pingidentity.com/pingfederate/pf84/index.shtml#concept_grantTypeParameters.html#concept_grantTypeParameters(请参阅访问令牌validation授予types )。 它使用基于REST的交互,这与OAuth 2非常相辅相成。

更新于201511月 – 按照下面的Hans Z. – 现在的确被定义为RFC 7662的一部分。

Google的方式

Google Oauth2令牌validation

请求:

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 } 

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.comhttp://img.dovov.comerror/octocat_happy.gif", "gravatar_id": "somehexcode", "url": "https://api.github.com/users/octocat" } } 

亚马逊方式

使用Amazonlogin – 开发者指南(2015年12月,第21页)

请求:

 https://api.amazon.com/auth/O2/tokeninfo?access_token=Atza|IQEBLjAsAhRmHjNgHpi0U-Dme37rR6CuUpSR... 

回应:

 HTTP/ll 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.的答案更新:资源服务器与授权服务器之间用于令牌validation的接口已于2015年10月在IETF RFC 7662中进行了标准化,请参阅: https : //tools.ietf.org/html/rfc7662 。 示例validation调用将如下所示:

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

当然,供应商和产品的采用将会随着时间的推移而发生。

OAuth v2规范指出:

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

我的授权服务器有一个web服务(SOAP)端点,它允许资源服务器知道access_token是否有效。

OAuth 2.0规范没有定义该部分。 但是可能有几个选项:

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

  2. Authz服务器可以使用私钥对令牌进行encryption/签名,然后将publickey / cert授予资源服务器。 当资源服务器获得令牌时,它要么解密/validation签名来validation令牌。 取出内容并处理令牌。 然后它可以提供访问或拒绝。