クライアントが OAuth 2.0 アクセス トークンで保護されたリソースを取得するようにリソース サーバーに要求した場合、このサーバーはどのようにトークンを検証しますか? OAuth 2.0 リフレッシュ トークン プロトコル?
6 に答える
グーグルウェイ
リクエスト:
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 のやり方
リクエスト:
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 - 開発者ガイド (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
}
2015年11月の更新:以下のHans Z.によると、これは実際にRFC7662の一部として定義されています。
元の回答: OAuth 2.0仕様(RFC 6749)は、アクセストークン(AT)検証のためのリソースサーバー(RS)と承認サーバー(AS)間の相互作用を明確に定義していません。それは実際にはASのトークンフォーマット/戦略に依存します-一部のトークンは( JSON Webトークンのように)自己完結型ですが、他のトークンは、サーバー側でASに保持されている情報を参照するだけであるという点でセッションCookieに似ている場合があります。
OAuthワーキンググループでは、RSがAT検証のためにASと通信するための標準的な方法を作成することについていくつかの議論がありました。私の会社(Ping Identity)は、商用OAuth AS(PingFederate)のそのようなアプローチの1つを考え出しました:https ://support.pingidentity.com/s/document-item?bundleId = pingfederate-93&topicId = lzn1564003025072.html#lzn1564003025072__section_N10578_N1002A_N10001 。これには、OAuth2.0を非常に補完するRESTベースの対話を使用します。
@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"
}
もちろん、ベンダーや製品による採用は、時間をかけて行わなければなりません。
OAuth 2.0 仕様では、この部分は定義されていません。ただし、いくつかのオプションがあります。
リソース サーバーは、Authz ヘッダーでトークンを取得すると、Authz サーバーで検証/イントロスペクト API を呼び出してトークンを検証します。ここで、Authz サーバーは、DB ストアを使用するか、署名と特定の属性を検証して、それを検証する場合があります。応答の一部として、トークンをデコードし、トークンの実際のデータと残りの有効期限を送信します。
Authz Server は秘密鍵を使用してトークンを暗号化/署名し、publickey/cert を Resource Server に渡すことができます。リソースサーバーがトークンを取得すると、署名を復号化/検証してトークンを検証します。コンテンツを取り出してトークンを処理します。次に、アクセスを提供するか、拒否することができます。
OAuth v2 仕様は次のことを示しています。
保護されたリソースにアクセスするために使用されるアクセス トークンの属性とメソッドは、この仕様の範囲を超えており、コンパニオン仕様で定義されています。
私の認可サーバーには、リソース サーバーが access_token が有効かどうかを認識できるようにする Web サービス (SOAP) エンドポイントがあります。