文字で読みたい2分間OAuth講座 : (5) Secret of Authorization Code, (6) Actors of OAuth

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

文字で読みたい2分間OAuth講座 : (3) Where are Sender Constrained Tokens used?, (4) Why Refresh Token? - r-weblife の続きで、今日は第5,6回の内容を紹介していきます。

動画をまだみてない人は、まずチャンネルチャンネルをサブスクライブして見てください。

www.youtube.com

では見ていきましょう。

(5) Secret of Authorization Code

www.youtube.com

これまでに、Access Token と Refresh Token を取り上げてきました。
今回はもう一つのトークン、 Authorization Code についての説明です。

Authorization Code は、ブラウザを経由して、Authorization Server から Client に渡されます。

f:id:ritou:20180925003339p:plain

仕様やフローの話をしているときに Authorization Code はトークンと呼ばれませんが、実際はトークンであり、Client の要求に対する Resource Owner(いわゆるユーザー) の許可を具体化しています。

f:id:ritou:20180925003852p:plain

そして、Authorization Code は一般的に、User Constrained Token です。(User Constrained Token とは?となったら振り出しに戻りましょ! 文字で読みたい2分間OAuth講座 : (1) The Basic Concepts (2) Bearer and Sender Constrained Tokens - r-weblife)

  • Authoization Code は Client に紐づけられている
  • Client は Client ID / Secret と共に Authorization Code を Authoization Code を送り直すことで、自分が紐づけられた Client であることを証明しつつ Access Token などを要求する

よって、Authorization Code のみを第3者に取得されても"大きな問題"にはなりません。 (モバイルアプリケーションなどで Client Secret を安全に保管できない環境で Authorization Code を取得されると Client になりすましてAccess Token などを取得されてしまうリスクはありますし、その対策もありますがここでは省略します。)

なぜこのようなステップを踏んでいるのか、その理由は Authorization Code が Client に渡される経路にあります。 Authorization Code は Resource Owner のブラウザを経由して(リダイレクトを利用して) Client に渡されます。 そのため、通信が完全には守られておらず、この経路で発行されるトークンはサーバー間の通信でやり取りされるよりも第3者に取得される可能性があります。

f:id:ritou:20180925005703p:plain

よって、このような経路で Bearer Token を送るのは BAD Idea ということです。(Implicit Grant についてはまた別途...)

f:id:ritou:20180925005901p:plain

ということで、第5回の内容は

  • Authorization Code というトークンがある
  • ブラウザ経由で送られることで盗まれる可能性があるため、User Constrained である

というあたりでしょうか。

(6) Actors of OAuth

www.youtube.com

第6回は、OAuth 2.0 における登場人物について説明します。

RFC 6749 - The OAuth 2.0 Authorization Framework では4種類の登場人物が出てきます。

f:id:ritou:20180925023909p:plain

  1. Client : Protected Resource へのアクセスを行いたいエンティティ。地下鉄の例でいうと、乗客。
  2. Authorization Server : Client に各種トークンを発行するエンティティ。地下鉄の例でいうと、券売機。
  3. Resource Server : Client が Access Token を用いてアクセスする先。地下鉄の例でいうと、改札で守られた中のサービス。
  4. Resource Owner : Client にリソースアクセスを許可する人。地下鉄の例では直接出てこなかった。

Resource Owner について、地下鉄の例では、乗車料金を決める地下鉄会社の社長がその立場にあたります。 券売機では料金を払えば改札を通れる切符が買えます。そのため、実際は認可を求められるたびに出てきて許可を与える必要がありません。 SNSのユーザー情報へのアクセスを外部のサービスが要求するような場合、ユーザーが Resource Owner になって Client に許可を与えます。

ということで、第6回は OAuth の登場人物についてのお話でした。

次回予告

次回は、

  • (7) When can one use password grant?
  • (8) ROPC (Password Grant) the Migration Tool

という、パスワードを扱うフローについての回を説明します。 気になる方はチャンネルをサブスクライブして今から見ちゃいましょう。

www.youtube.com

ではまた。