リソースサーバーのOAuth 2.0アクセストークンを検証する方法

クライアントがOAuth 2.0アクセストークンで保護されたリソースを取得するようにリソースサーバーに要求した場合、このサーバーはどのようにトークンを検証しますか？OAuth 2.0更新トークンプロトコル？

2015年11月更新：以下のHans Z.による-これは実際にRFC 7662の一部として現在定義されています。

元の回答： OAuth 2.0仕様（RFC 6749）では、アクセストークン（AT）検証のためのリソースサーバー（RS）と承認サーバー（AS）間の相互作用を明確に定義していません。それは実際にはASのトークン形式/戦略に依存します-一部のトークンは自己完結型（JSON Web Tokenのように）ですが、他のトークンはASでサーバー側に保持された情報を参照するだけでセッションCookieに似ています。

AT検証のためにRSがASと通信するための標準的な方法を作成することについて、OAuthワーキンググループでいくつかの議論がありました。私の会社（Ping Identity）は、商用OAuth AS（PingFederate）にこのようなアプローチを1つ考案しました：https ://support.pingidentity.com/s/document-item?bundleId=pingfederate-93&topicId=lzn1564003025072.html#lzn1564003025072__section_N10578_N1002A_N10001 。これには、OAuth 2.0を非常に補完するRESTベースの相互作用を使用します。

グーグルウェイ

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
}

@Scott T.の回答の更新：トークン検証のためのResource ServerとAuthorization Serverの間のインターフェイスは、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"
}

もちろん、ベンダーや製品による採用は、時間の経過とともに発生する必要があります。

OAuth 2.0仕様ではその部分を定義していません。しかし、いくつかの選択肢があるかもしれません：

1. リソースサーバーがAuthzヘッダーでトークンを取得すると、Authzサーバーの検証/イントロスペクトAPIを呼び出してトークンを検証します。ここで、Authzサーバーは、DBストアを使用するか、署名と特定の属性を検証することで、それを検証する場合があります。応答の一部として、トークンをデコードし、残りの有効期限とともにトークンの実際のデータを送信します。

2. Authzサーバーは秘密キーを使用してトークンを暗号化/署名し、パブリックキー/証明書をリソースサーバーに提供できます。リソースサーバーがトークンを取得すると、署名を復号化/検証してトークンを検証します。コンテンツを取り出し、トークンを処理します。その後、アクセスを提供するか、拒否することができます。

OAuth v2仕様は次のことを示しています。

保護されたリソースへのアクセスに使用されるアクセストークン属性とメソッドは、この仕様の範囲外であり、コンパニオン仕様で定義されています。

私の承認サーバーには、リソースサーバーがaccess_tokenが有効かどうかを確認できるようにするWebサービス（SOAP）エンドポイントがあります。