おはようございます！こんにちは！こんばんは！ ritouです。
(2019/4/1 : Sender Constrained Token と表記する部分を User Constrained Token としていたので修正しました。ご指摘ありがとうございます！)
文字で読みたい2分間OAuth講座 : (1) The Basic Concepts (2) Bearer and Sender Constrained Tokens - r-weblife の続きで、第3, 4回目について説明します。
(3) Where are Sender Constrained Tokens used?
第2回で登場した Sender Constrained Token ですが、OAuth 2.0のどこで使われているのでしょうか？ RFC6749には出てこない？それでは見ていきましょう。
OAuth 2.0のフローのうち、最も使われているのは Authorization Code Grant と呼ばれるものです。 その中で出てくるトークン(的なもの)に Sender Constrained Token が含まれています。 ここからじゃんじゃんスクショ貼って行くぞ！
Authorization Code Grant
ユーザーは Web アプリケーションである Client のサービスをブラウザから使おうとします。
ブラウザは Client にリクエストを送ります。
Client は認可リクエストを生成します。
Client はブラウザのリダイレクトを利用してユーザーを Authorization Server に送ります。
Authorization Server はユーザー認証をします。
Authorization Server は Client が要求している内容をユーザーに示して、承認を求めます
ユーザーが承認のアクションをとります。
Authorization Server は Client (のID)に紐づいた"Authorization Code"と呼ばれる "Sender Constrained Token" を生成します。
Authorization Server はブラウザのリダイレクトを利用して、"Authorization Code" を含む認可応答を Client に返します。
Client は "Authorization Code"、Client ID、Secret を含むトークン要求を Authorization Server に送ります。 Clientは自らを認証するためにClient IDとSecretを含みます。
Authorization Server は、トークン要求に含まれる "Authorization Code" が正しい Client から送られてきたものか確認します。
"User Constrained Token" 的には、
- Authorization Code に紐づく Client とトークン要求を送った Client が一致すること
- Client ID / Secret の組み合わせが正しいこと
という確認をすることで正しいClientから送られてきたとみなします。
Authorization Server は "Access Token" と "Refresh Token" を返します。 ここで、RFC6749(+RFC6750の組み合わせ)の"Access Token"は、 "Bearer Token"、"Refresh Token" は "Sender Constrained Token" です。
Client は Access Token を利用してリソースアクセスを行います。あとはよしなに。
まとめ
第3回のまとめとしては、
- OAuth 2.0 の Authorization Code Grant について説明した
- その中で出てくる、"Authorization Code" と "Refresh Token" は いわゆる "Sender Constrained Token" である
- 他に "Sender Constrained Token" の使いどころを知りたければ、"FAPI" で検索しましょう。
となります。
ここでなぜ Refresh Token の使い方を説明しないのかと思われるでしょう。 第4回は "Refresh Token" についての内容となります。
(4) Why Refresh Token?
Refresh Token は Authorization Server に対して"のみ"利用されるトークンです。 第4回では、OAuth 2.0 の Refresh Token がなぜ必要なのかについて説明します。
OAuth 2.0 の Access Token は、(scopeの概念を入れなければ)複数の Protected Resource に対して利用できます。
"Access Token" が "Bearer Token" であり、Protected Resource のいずれかがハックされて攻撃者の支配下に置かれた場合を考えます。
攻撃者はハックした Protected Resource にて取得した "Access Token" を用いて、別の Protected Resource にアクセスできます。
第3者に "Bearer Token" を使われてしまう、このような被害を"軽減"させるために、"Access Token" に短い有効期限を設定する方法があります。
有効期限を短く設定することで、頑張って "Access Token" を取得できた攻撃者が別の Protected Resource に利用しようとしてもエラーとなります。
しかし、Client が "Access Token" のみを保存して利用する場合、ユーザーに対して頻繁にリソースアクセスの承認を求める必要があり、ユーザーがオンライン状態でなければゲームオーバーです。オンラインだったとしてもメンドクセ。
この状況を改善するため、 "Refresh Token" が利用されます。 "Refresh Token" は Authorization Server だけに送られるトークンであり、通常は長い有効期限が設定されています。 Protected Resource をハックした攻撃者に "Refresh Token" が送られることはありません。 Client はこれを Authorization Server に送り、新しい Access Token を取得します。 Access Token を Refresh するためのトークンなので "Refresh Token" と言うわけです。 ちなみに、第3回で説明した通り "Refresh Token" は”Sender Constrained Token” なので、Client ID / Secret などと共に送られ、Authorization Server は検証を行います。
と言うことで、第4回は "Bearer Token" な "Access Token" を悪用されるリスクを軽減されるために、"Refresh Token" が使われるよっていうお話でした。
今回は動画をそのまま文字にするだけじゃなくて、色々補足しようと思ったら長くなりました。これが良いのかどうかはわからん... 次回予告です。
- (5) Secret of Authorization Code : Authorization Code についての説明!?
- (6) Actors of OAuth : 第1回よりもちょっと詳しく登場人物を説明!?
ではまた。
この投稿をみて、動画に興味を持っていただいた方は是非、チャンネルをサブスクライブしてください！！！ www.youtube.com
