当客户端请求资源服务器获取具有 OAuth 2.0 访问令牌的受保护资源时，该服务器如何验证令牌？ OAuth 2.0 刷新令牌协议？
谷歌方式
Google Oauth2 Token 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
}
微软方式
Microsoft - Oauth2 check an authorization
Github方式
Github - Oauth2 check an authorization
要求：
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"
}
}
亚马逊方式
Login With Amazon - Developer Guide (Dec. 2015, page 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
}
2015 年 11 月更新：根据下面的 Hans Z. - 现在确实将其定义为 RFC 7662 的一部分。
原始答案： OAuth 2.0 规范 (RFC 6749) 没有明确定义资源服务器 (RS) 和授权服务器 (AS) 之间的交互以进行访问令牌 (AT) 验证。这实际上取决于 AS 的令牌格式/策略 - 一些令牌是自包含的（如 JSON Web Tokens），而其他令牌可能类似于会话 cookie，因为它们只是引用保存在 AS 的服务器端的信息。
OAuth 工作组中有 some discussion 关于创建 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. 回答的更新：用于令牌验证的资源服务器和授权服务器之间的接口于 2015 年 10 月在 IETF RFC 7662 中标准化，请参阅：https://www.rfc-editor.org/rfc/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 Header 中获取令牌时，它会调用 Authz 服务器上的 validate/introspect API 来验证令牌。在这里，Authz 服务器可能会通过使用 DB Store 或验证签名和某些属性来验证它。作为响应的一部分，它解码令牌并发送令牌的实际数据以及剩余的到期时间。 Authz Server 可以使用私钥对令牌进行加密/签名，然后可以将 publickey/cert 提供给资源服务器。当资源服务器获取令牌时，它要么解密/验证签名以验证令牌。取出内容并处理令牌。然后它可以提供访问或拒绝。
2021 年更新的答案
通常不建议您自行推出 OAuth 2 / OIDC 实施的任何部分，尤其是现在令牌自省是 part of the standard。就像尝试推出自己的加密库一样，使用如此复杂的规范很容易犯严重错误。
Here's a list 个实施 OAuth 2 的其他语言的推荐库。Here's another 个已通过 OpenID 基金会认证；其中许多库也实现了 OAuth 2。
如果您在 .NET 中并使用 IdentityServer 库（版本 2.2 及更高版本），则 introspect endpoint 完全可以完成此操作。它作为 discovery document（也是 standard）的一部分发布，并且是资源服务器可以验证访问令牌的端点。
如果您已经走到了这一步，但仍然真的想自己动手，请从 how the bigger libraries have done it 那里获得一些提示。
OAuth v2 规范表明：
访问令牌属性和用于访问受保护资源的方法超出了本规范的范围，由配套规范定义。
我的授权服务器有一个 Web 服务 (SOAP) 端点，允许资源服务器知道 access_token 是否有效。
