如何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非常相辅相成。
–
更新于2015年11月 – 按照下面的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规范没有定义该部分。 但是可能有几个选项：
-
当资源服务器在Authz Header中获取令牌时，它会调用Authz服务器上的validate / introspect API来validation令牌。 这里Authz服务器可以使用数据库存储或validation签名和某些属性来validation它。 作为响应的一部分，它解码令牌并发送令牌的实际数据以及剩余的到期时间。
-
Authz服务器可以使用私钥对令牌进行encryption/签名，然后将publickey / cert授予资源服务器。 当资源服务器获得令牌时，它要么解密/validation签名来validation令牌。 取出内容并处理令牌。 然后它可以提供访问或拒绝。
