Hatena::ブログ(Diary)

r-weblife RSSフィード Twitter

2015/11/04

OpenID Connectのセッションに関する3つの仕様について

おはようございます、ritouです。

OpenID Summit Tokyo 2015までもうちょいですね。

プログラムを見てみましょう。

OpenID Summit Tokyo 2015

仕様の話もありそうですね。

今回はRFCXXXXとして発行された系ではなく、OpenID Foundationで策定が進んでいるOpenID Connect関連の仕様を紹介します。

ドラフト仕様も、いろいろあります。

Specifications & Developer Information | OpenID

このうち、今回は次の3個の仕様をとりあげます。

  • Session Management – (Optional) Defines how to manage OpenID Connect sessions, including postMessage-based logout functionality
  • HTTP-Based Logout – (Optional) Defines an HTTP-based logout mechanism that does not use an OP iframe on RP pages
  • Back-Channel Logout – (Optional) Defines a logout mechanism that uses back-channel communication between the OP and RPs being logged out

この説明だけ見ると、みんなlogout言ってます。

これらがどう違うのかを確認していきましょう。

OpenID Connect Session Management 1.0 - draft 25

Draft: OpenID Connect Session Management 1.0 - draft 27

ざっくり書くと、

  • RPはAuthN Response(OAuthでいうところのAuthZ Response)でセッションに紐づく、session_stateという値を受け取る
  • RPはiframe + postMessageをつかって、OPにsession_stateを送り、状態変更があったかどうかを問い合わせる
  • RP始動なログアウトのときは、OPのログアウト用URL(end_session_endpoint)にリダイレクトする

という感じです。

そういえばずっと前に記事を書いた気がします。

OpenID Connectで異なるドメイン間のログインセッション不整合を防ぐ方法 - r-weblife

この時点から、そんなに変わってないです。

OpenID Connect HTTP-Based Logout 1.0 - draft 03

Spec obsoleted by openid-connect-frontchannel-1_0

(Session Managementに対して)RP上にiframeを必要としないHTTPベースのログアウトメカニズムを定義するとあります。

  • RPはログアウト用エンドポイントとセッションIDが必須かどうかをOPに登録、OPからiframeでそのエンドポイントを呼び出されたらログインセッションをクリアする
  • OPはログイン状態のRPを"visited site"Cookieのようなもので管理しておき、ログアウト時にiframeでそれぞれのログアウトURIを呼び出すことでRPに通知する
  • Session Management同様、RP始動なログアウトのときは、OPのログアウト用URLにリダイレクトする

ということで、Session Managementと並行して実装することもできます。

iframe対応をしなくてもOPの状態変更を知ることができるのは便利そうですね。

OpenID Connect Back-Channel Logout 1.0 - draft 01

Draft: OpenID Connect Back-Channel Logout 1.0 - draft 03

HTTP-Based Logoutとは異なり、OP-RP(複数の場合もあり)間のバックチャンネルコミュニケーションを用いてログアウトさせます。

Session Managementなんかはiframeで問い合わせるページをユーザが開いていなければチェックができないなどUser-Agentがアクティブである必要がありますが、バックチャンネルだと気にしなくていいです。

その代わり、CookieとかHTML Strageとかでさくっと実装できる感じではないので、サーバサイドでセッションを切るような作りにしなければとか、よくあるFirewall/NATの話とかがIntroductionに書いてあります。

定義されているものは

  • OPはログイン状態のRPを覚えておく必要がある(セッションに対して、ユーザーとRP一覧を紐づけておく)
  • ID Tokenに似ているLogout Tokenと呼ばれるものがバックチャンネルで送られる。Logout Tokenのsub/sidあたりを
  • 上記2つの仕様と同様、RP始動なログアウトのときは、OPのログアウト用URLにリダイレクトして、OPに行った後はそのあとバックチャンネルの処理になる

という感じです。詳細は長くなるので省略します。

気になるこまけぇこと

  • Session StateでAuthN Responseで受け取るユーザのログイン状態はsession_state
  • 他の2つのLogout関連の仕様では、セッション識別子はsidとしてID Tokenに含まれる

用途としてはたしかに別なので、こうなる気持ちはわかります。

が、一般的にユーザがログアウトしたらセッションIDを破棄すべきという話もあるので、session_stateとsidは統一できそうな気がします。

渡し方については...これはちょっと考えないといけませんね...

まとめ

  • OpenID Connectのセッション関連の仕様は3つある
  • Session Management : iframeを用いたRP->OPのログイン状態の問い合わせ方とRP始動ログアウト時のOPへのリダイレクト
  • HTTP-Based Logout : RPはOPからiframeで対象エンドポイントが呼び出されたらログアウト処理
  • Back-Channel Logout : RPはバックチャンネルでlogout tokenを受け取ったらログアウト処理

なんとなく違いがおわかりいただけたでしょうか。

このあたりは、時間を見つけてデモ環境を作りたいと思います。

ではまた!

2015/10/21

RFC7662として発行されたOAuth Token Introspectionとは

こんばんは、ritouです。

今回紹介する仕様は、RFC7662 OAuth Token Introspectionです。

ざっくり言うと

Token Introspectionとかいうと、Token置換攻撃対策としてのClient-AuthZ Server間のAccess Token検証を想像する方もいるかもしれませんが、この仕様はそれとはあまり関係ありません。

この仕様はOAuthのProtected Resourceのための仕様です。

RFC 6749 - The OAuth 2.0 Authorization FrameworkのRoleのところには、resource serverがprotected resourceをホストしていて、 access tokenを用いたリクエストを受ける、とあります。

簡単に言うと、APIサーバのことですね。

AuthZ ServerとResource Serverが分かれることはよくある話です。

小規模なところは、裏で同じDBを見に行くなどしてAccess Tokenの検証をすればよいわけですが、そこそこの規模のサービスだとか、ID統合など諸々の理由でそういうつくりができないこともあるでしょう。

また、最近はなんたらAPI Gatewayみたいなやつが最初にリクエストを受け、Resource Serverに来る前にAccess Tokenの検証ができるみたいな構成も聞きます。

この仕様はそういうのではなく、"Resource Serverが受け取ったAccess Tokenの状態をAuthZ Serverに問い合わせる"ような状況において、Access Tokenの送り方(問い合わせ方)を定義したものです。

ここからは、RFCの構成を意識しながら説明していきます。

課題

Introductionに書いてあります。

  • OAuth 2.0の仕様で、Access Tokenは、"The string is usually opaque to the client."となっている
  • Protected Resourceの処理には、Tokenが有効かどうかや紐づいたユーザー情報、認可に関する情報などが必要である
  • しかし、OAuth2.0ではProtected Resourceがそれらを知る方法が具体的に定義されていないので、JWTとか独自の内部処理とかでの対応が必要となる(ので、例えばこんな提案とかが出回るわけです→OAuth 2.0のAccess TokenへのJSON Web Token(JSON Web Signature)の適用 - r-weblife)

この仕様が定めること

  • Protected ResourceがClientから受け取ったTokenのメタデータをAuthZ Serverに要求する方法
  • メタデータはTokenの有効性や許可されたアクセス範囲、認可情報などを含む
  • Token文字列自体がメタデータを含んでいるかどうかにかかわらず、この方法を利用できる

Protected Resourceが扱うのはAccess Tokenですが、仕様上はAccess TokenだけではなくRefresh Tokenでもいいみたいです。

Introspection Endpoint

AuthZ ServerはProtected Resourceからの要求を受けるエンドポイントを用意する必要があります。

  • Tokenを受け取ってメタデータをJSON形式で返すエンドポイント.
  • トランスポート層で保護されなければならない

AuthZ ServerがProtected Resourceにこのエンドポイントをどうやって教えるかなどは仕様の対象外です。

まずはリクエストの説明からです。

Introspection Request

Protected Resourceは"application/x-www-form-urlencoded"形式で次のパラメータを持つHTTP POSTなリクエストを送ります。

  • token : REQUIRED。access_token、refresh_tokenなどの値を指定します。
  • token_type_hint : OPTIONAL。RFC 7009 - OAuth 2.0 Token Revocationで定義されており、"access_token", "refresh_token"の値が入る。

token scanning attackを防ぐため、このエンドポイントにアクセスするためのProtected Resource - AuthZ Server間の認可が必須です。

この認可については仕様対象外なので何でもいいんですが、OAuth 2.0の仕様に準拠させた例が載っています。

説明すると逆に混乱しそうですが、"AuthZ Serverにとって、Protected ResourceはIntrospection endpointにアクセスしてくるClientである"という感じです。

# client authenticationと組み合わせた例
POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

token=mF_9.B5f-4.1JqM&token_type_hint=access_token

# bearer tokenを用いる例
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

次はレスポンスの説明です。

Introspection Response

レスポンスはJSON("application/json")形式です。

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

必須なのは、activeという値(boolean)で、Tokenが有効かどうかが入ります。

それ以外で気になるのがあったら仕様を読みましょう。

JWTのClaimについてはRFC 7519 - JSON Web Token (JWT)を読むといいでしょう。

Security Considerationsも流し読みしておきます。

Security Considerations

  • AuthZ ServerのTokenチェックをしっかりやろう
  • 前述したような攻撃を防ぐために、Protected Resourceの認証、Introspection Endpointへアクセスできるかどうかの確認をしっかりやろう
  • TLS/SSLのサーバーチェックとかしっかりやろう
  • AuthZ Serverのサーバーサイドのログからの漏えいを防ぐため、GETじゃなくPOST
  • キャッシュすると無効化の同期が...
  • Token文字列が構造化されてたらどうこう...

みたいなことが書いてあります。

実際こういうしくみを作ろうと思うと、負荷のあたりは悩ましげな感じですねー。

Privacy Considerations

レスポンスにセンシティブなプライバシー情報を含む場合があるのでほげほげ。

まとめ

  • Protected Resource(を持ってるResource Server)からAuthZ ServerへのToken情報の要求方法が定義されている
  • HTTP POSTのリクエストでTokenを送るときに、Protected Resource - AuthZ Server間の認証/認可が必要
  • レスポンスに"Tokenが有効かどうか"は必須

個人的には...小規模だとなかなか使わないし、すごい大規模になると負荷とかでもっと工夫しそうなので、異なる企業間をまたいだ疎結合なシステムのときにAPIでつなぐのかなーとか想像しちゃうところです。

ではまた!

2015/10/18

RFC7636として発行されたOAuth PKCEとは

おひさしぶりです、ritouです。

今日は家で風邪治してましたが、TLに流れてきた次世代なんちゃらの話題に乗っかって、ざっくりとした仕様紹介です。

一言でいうと

この規格はOAuth 2.0 [RFC6749]のPublic Client の Code Interception Attack 脆弱性に対応するもので、ephemeral keyを生成して、これを使ったProof of Possession of Key をします。

OAuth PKCEがRFC7636として発行されました。 | @_Nat Zone

なんですが、RFCの構成を意識して書いていきます。

問題

RFCでは、Introductionに書いてあります。

OAuth 2.0 [RFC6749] public clients are susceptible to the authorization code interception attack.

RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients

Public Clientってのは、client_secretを安全に管理できないclientですね。

そういうclientはimplicitでは?って思われる人もいるかもしれませんが、落ち着きましょう。

Public ClientがAuthZ Codeを使う場合、次のようなフローになります。

  1. Clientは外部ブラウザを立ち上げるなりして、AuthZ Reqを送る
  2. AuthZ Serverに送られ、ログインとか何とかした後にAuthZ CodeがブラウザからClientに返される
  3. Clientは、AuthZ CodeとClient CredentialをAuthZ ServerのToken Endpointに送って、Access Tokenを取得する

これでPublic Clientの場合にどこがどうなっててどう危ないか、後ろから見ていくとわかるものです。

  • Access Tokenを取得するためには、AuthZ CodeとClient Credentialが必要!
  • Public Clientなので、Client Credentialを知ることができる。つまり、AuthZ CodeがあればAccess Tokenを取得できる!
  • もし、カスタムURIスキームとか使ってAuthZ Codeの受け渡しのときに攻撃者にAuthZ Codeが渡ったら...AccessTokenを取得される問題!

ということですね。

解決方法

こちらもIntroductionに書いてあります。

To mitigate this attack, this extension utilizes a dynamically

created cryptographically random key called "code verifier". A

unique code verifier is created for every authorization request, and

its transformed value, called "code challenge", is sent to the

authorization server to obtain the authorization code. The

authorization code obtained is then sent to the token endpoint with

the "code verifier", and the server compares it with the previously

received request code so that it can perform the proof of possession

of the "code verifier" by the client. This works as the mitigation

since the attacker would not know this one-time key, since it is sent

over TLS and cannot be intercepted.

RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients

ここでは翻訳したいわけじゃないので...

  • Clientはcode verifierっていう、動的に生成されるcryptographically random key(←妥協)を生成
  • code verifierは毎回AuthZ Req毎に生成される
  • Clientは(code verifierを変換した)code challengeというパラメータをAuthZ Reqに含み、AuthZ ServerのAuthZ Endpointに送る
  • AuthZ ServerはAuthZ Codeとcode challengeを紐づけつつ、Clientのredirect_uriにAuthZ Codeを送る
  • Clientは、AuthZ Codeとcode verifierを一緒にAuthZ ServerのToken Endpointに送る
  • AuthZ ServerはAuthZ Codeと紐づけておいたcode challengeとcode verifierの値を検証し、Access Tokenを返す
  • 攻撃者はcode verifier知らないのでAuthZ Codeを奪うだけではAccess Token取得できない

こんな感じです。

ここまでで大事なことは書いたので、後はざっと流しましょう。

用語

  • code verifier : 動的に生成されたcryptographically random stringであり、Token EndpointへのAccess Token Reqに含まれる
  • code challenge : code verifierから生成されたchallengeの値で、AuthZ EndpointへのAuthZ Reqに含まれる
  • code challenge method : code verifierからcode challengeを作る時の方法
  • Base64url Encoding : 省略

code verifierの生成

最小43文字、最大128文字の...

code_verifier = high-entropy cryptographic random STRING using the

unreserved characters [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~"

from Section 2.3 of [RFC3986], with a minimum length of 43 characters

and a maximum length of 128 characters.

ABNF for "code_verifier" is as follows.

code-verifier = 43*128unreserved

unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

ALPHA = %x41-5A / %x61-7A

DIGIT = %x30-39

RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients

code challengeの生成

code challengeの生成方法について、plainとS256が記載されています。

plain

code_challenge = code_verifier

S256

code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients

ABNF for "code_challenge" is as follows.

code-challenge = 43*128unreserved

unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

ALPHA = %x41-5A / %x61-7A

DIGIT = %x30-39

RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients

ClientはS256できるならS256使う。どうしようもなかったらplain。

AuthZ Reqへの追加パラメータ

code challengeとmethodを指定します。

code_challenge

REQUIRED. Code challenge.

code_challenge_method

OPTIONAL, defaults to "plain" if not present in the request. Code

verifier transformation method is "S256" or "plain".

RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients

AuthZ Resについて

AuthZ ServerはAuthZ Codeとcode_challenge, code_challenge_methodは返してはいけません。

method=plainだったらcode verifierそのものですからね。

Access Token Reqへの追加パラメータ

code_verifier

REQUIRED. Code verifier

RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients

AuthZ Serverの検証について

  • code_challenge_methodの値に従って、code_verifierそのままもしくはs256した値とcode_challengeの値を比較する

Security Considerations

は、読んでおきましょう(疲れた)

まとめ

  • Public ClientからAuthZ Code使ってAccess Tokenを取得する場合のお話
  • Clientは毎回動的にcode verifierを生成する
  • これ使うと、redirect_uriの扱いが不安なPublic Clientでも、安全にAccess Tokenの取得が行えそう

文章だけでまだわからんので絵が欲しい って場合は、この記事をTweetしたついでに一言いただけると対応できるかもしれません。

ではまた!

2015/04/20

Auth0のドキュメントに書いてあったMQTTをWeb APIっぽく使うための工夫

どーも、ritouです。

一言でいうと、MQTTでもTokenを使えそうというだけの話

MQTTに関して、様々な言語のライブラリや、他の機能と連携するプラグインなどもよく見かけます。

詳細な解説記事からさくっと使って「簡単でした!」みたいな記事までたくさん出回っておりますが、その中で、MQTTのAuthN&AuthZに着目した内容に触れているドキュメントを見つけました。

https://auth0.com/docs/scenarios/mqtt

Auth0ってのはIdentity as a Service、クラウドな認証基盤なサービスなんて紹介されたりしてるサービスです。

で、上記のドキュメントは”Authenticating & Authorizing Devices using MQTT with Auth0” というタイトルのとおり、ざっくり言うと

  • CONNECT時のusername/passwordとAuth0を用いて接続元デバイスの検証を行う = Authentication
  • PUB/SUB時にAuth0を用いて接続元デバイスとTopicの組み合わせの検証を行う = Authorization

という感じで、2種類の方法が紹介されています。

  • (1) MQTT Clientは普通の使い方、MQTT BrokerがAuth0に問い合わせる

f:id:ritou:20150420132335p:image:w360

  • (2) MQTT ClientはAuth0からTokenを取得し、"username/password"のところに"'jwt'/(取得したToken文字列)"を指定し、BrokerはTokenの検証を行う

f:id:ritou:20150420132336p:image:w360

(2)は個人的に大好物であるところのOAuthなWeb APIっぽい使い方に見えます。

username/passwordのところに違う値をぶっこむというやや強引なやり方ですが、Tokenの検証などについては前に書いたやつと同じ感じの設計でいけそうです。

OAuth 2.0のAccess TokenへのJSON Web Token(JSON Web Signature)の適用 - r-weblife

Moscaはこのあたりを試すのに便利

そもそもMQTT Brokerをしっかり実装しようとすると大変そうだし、さらにTokenを使うように拡張なんて...と思われるのはないでしょうか。

Auth0は、Node製のMQTT BrokerであるMoscaを利用しています。

Moscaでは、AuthN/AuthZに関連する機能を拡張しやすいつくりになっています。

With Mosca you can authorize a client defining three methods.

  • #authenticate
  • #authorizePublish
  • #authorizeSubscribe

Those methods can be used to restric the accessible topics for a specific clients.

https://github.com/mcollina/mosca/wiki/Authentication-&-Authorization

使い方はAuth0Moscaのサンプルを見るとわかりやすいです。

var auth0 = new Auth0Mosca(...);

//Setup the Mosca server
var server = new mosca.Server(...);

//Wire up authentication & authorization to mosca
server.authenticate = auth0.authenticateWithJWT();
server.authorizePublish = auth0.authorizePublish();
server.authorizeSubscribe = auth0.authorizeSubscribe();

Productionで使うとなると「接続/Pub数の制限とか、もっといろんな独自処理を挟みたい vs パフォーマンスがー問題」とか、いろいろ出てくるんでしょうけども、ちょっと試すには便利そうです。

まとめ

  • Auth0が出しているMQTT利用シナリオにあった、Tokenを用いる方法がWebAPIっぽいなーと思って紹介した
  • そのあたりの拡張が簡単にできるMoscaは、ちょっと遊ぶには便利そうな印象

そういえば、BaaSにもサーバーサイドスクリプトってのがあります。

MQTT as a Serviceを提供するようなところでもこのあたりの拡張ができて自サービスで発行したOAuthのAccess Tokenなどが使えると、MQTT Broker自体のパフォーマンスを下げずに既存のサービスとの親和性も高められてさらに便利かなーと思いました。

ではまた!

2014/09/27

OAuth 2.0のAccess TokenへのJSON Web Token(JSON Web Signature)の適用

こんばんは、ritouです。

久々の投稿な気がしますが、今回はOAuth 2.0のリソースアクセス時の設計の話です。

ずーっと前から書こうと思いつつ書いてなかったので、ここに書いておきます。

出てくる用語や仕様は、下記の翻訳リンクを参照してください。

想定する環境

わりとよくある環境を想定しています。

f:id:ritou:20140927184903p:image:w640

  • OAuth 2.0で認可サーバーとリソースサーバーがある
  • 認可サーバーがAccess Tokenを発行
  • リソースサーバーがAPIリクエストに含まれるAccess Tokenを検証する

よくある実装とその悩みどころを、JSON Web Token(JSON Web Signature)により軽減できるかもという話です。

よくある実装 : Access Tokenに一見ランダムな文字列を利用、DBなりで紐付け

パフォーマンスとか無視して素直に実装しようとするとこんな感じになるのではないでしょうか?

認可サーバー
  • 認可情報を(DBなどに)保存 : user_id, client_id, scope, 有効期限など
  • Access Tokenはランダムっぽい文字列を利用して、それらと紐付けられる
リソースサーバー
  • Access Tokenの文字列を利用してDB接続や認可サーバーへのHTTPリクエスト、その他いろいろな手段でAccess Tokenに紐づく情報を問い合わせる : Access Tokenが有効であることを確認

認可サーバーにHTTPなどで問い合わせる感じだと、こんな図になるでしょう。

f:id:ritou:20140927184904p:image:w640

この場合、基本的に受け取ったAccess Tokenに対して全て問い合わせが走るので、どうしても負荷がきつくなりがちでしょう。

無駄な問い合わせを省略するためには、Access Tokenにタイムスタンプ含めるとか、文字列のフォーマットをチェックするとかはできるかもしれませんが、規模が大きくなると辛いのかなと思ったりします。

提案 : JWT(JWS)形式のAccess Tokenに情報を詰め込む

JWTを用いて、リソースサーバーから認可サーバーへ問い合わせを減らせるのでは?という提案です。

認可サーバー
  • 認可情報を(DBなどに)保存 : user_id, client_id, scope, 有効期限など
  • "認可情報もしくはAccess Tokenに対して一意"なtoken_id的なものを払い出し、認可情報とは別で有効なtoken_idを管理しておく
  • 認可情報とtoken_idを含むJWT(署名つきなので正確にはJWS)をAccess Tokenの値とする
  • 署名には認可サーバーの秘密鍵を利用(alg=RS256とか)し、リソースサーバーには公開鍵を配布するなどして有効な公開鍵を確認できるようにしておく
リソースサーバー
  • Access Tokenの署名検証を行う : 認可サーバーが発行した文字列であることを確認
  • 有効期限を確認する : 有効期限内のAccess Tokenであることを確認
  • JWTに含まれるtoken_idが有効かどうかを認可サーバーに問い合わせる : 何らかの事情でAccess Tokenが無効化されていないことを確認

f:id:ritou:20140927184905p:image:w640

AccessTokenの有効期限を短くして最後のtoken_idのチェックをスキップみたいな話もあるが、今回は割愛します。

メリット/デメリット

メリット
  • リソースサーバーは無効なAccess Tokenを署名検証 + 有効期限チェックである程度判定できる
  • DBや認可サーバーも、token_idの管理だけできればいいので負荷が抑えられる
デメリット
  • リソースサーバー側で行う処理が増える。この手の処理はApacheモジュールとか、WAFのプラグインとかでやれるしくみを用意すると幸せになれそう
  • JWT使うとAccess Tokenの文字列は長くなる

Access TokenのPayloadサンプル

JWTのPayloadに含む最低限の値はこんな感じかと。token_idなんかはHeaderでも良いかも。

3文字ルールの中にtoken_idとかscopeとか入れるの気持ち悪かったら何でも良いですし、構造化されててもかまわないと思います。

{
 "sub": "(リソースオーナーのユーザー識別子)",
 "token_id": "(認可情報 or Access Tokenに対して一意な識別子)",
 "aud": "(client_id)",
 "exp": (有効期限のタイムスタンプ),
 "scope": "(このAccess Tokenに関連付けられたScope)"
}

まとめ

  • OAuth 2.0のリソースアクセスの部分で、ベタに実装すると負荷とかきつくなりそうな部分をJWTを用いて改善できるかもという話を書いたつもり
  • 昔からWebサービスのSession Cookieなどでこ独自encode+signatureとか使っているところはあったと思うし、SessionをCookieに保存するしくみがあるが、それにも適用可能(最近話題のmicroservicesとかでOAuth 2.0のAccess Tokenをサービス内で使ってるところとかも)

参考になりそうな資料

ではまた。