はじめに
OAuth(オーオース)の仕組みについて全く理解できていなかったので、こちらの記事を読み学ばさせていただきました。
OAuth 2.0 全フローの図解と動画
大まかにどんな役割をそれぞれの機能が担っているのかをざっくりと理解したので、噛み砕いて図解してみることにします。
※ 間違っていることを記述している可能性は大いにありますので、その都度ご指摘していただけると助かります。
リソースが返ってくるまでの流れ
登場人物
まず登場人物は４つ
- ユーザー ... 利用者
- クライアント ... アプリとか
- 認可サーバー ... 認可に関して管理する窓口
- リソースサーバー ... データとか商品とか持ってる
目的確認
ざっくりいうとこういうことしている。
①ユーザーはリソースサーバーが所持している商品がほしい
②アプリを使えばやり取りできる
③悪意あるユーザーの不正アクセスを防ぐために認可サーバーが認証のやりとりを行ってくれている
認可フロー
① 本人確認
前提として、新規登録は済んだ状態とします。
リソースがほしいユーザーに対してまず本人確認としてログインを求めます。
② 権限許可
ユーザーへこのクライアントアプリに権限を与えるか許可を求めます。
③ 認可コードでトークン発行
アクセストークン発行に必要な認可コードを発行します。
（認可コードは有効期限が短いので注意）
認可コードを使用して、アクセストークンを発行します。
同時にリフレッシュトークンも発行します。
④ 検証後、リソースをもらう
アクセストークンを使用し、検証後、リソースサーバーからリソースをもらう。
これでリソースGet
おおまかにいうとこういう仕組みだと思われます。
リフレッシュトークンについて
※ リフレッシュトークンについて、こちらのページを参考に記述しています。
OAuth 2.0 コード付与フローを使用して Azure Active Directory Web アプリケーションへアクセスを承認する
☆ ポイントは２つ
アクセストークンは有効期間が短く、期限が切れた後もリソースにアクセスし続けるためにはトークンを更新する必要があります。
このとき、有効期間が比較的長いリフレッシュトークンを使用します。
（いちいち有効期限の短い認可コードを発行しなくてよいということ）リフレッシュトークンは、クライアントが既にアクセスを同意されているすべてのリソースについて有効です。
リフレッシュトークンの有効期限が切れる、失効する、または目的の操作のための十分な特権がない等の場合はエラーとなります。
その場合、現在のリフレッシュトークンを破棄し、新しい認可コードを要求します。
アクセストークン検証について
図にはいらなかったのと手順が分かりづらくなりそうだったので省略しましたが、検証が成り立つために、こんな感じのやりとりがあります。
ただ検証方法には、識別子型、内包型、ハイブリット型とやり方が複数あり、そもそも認可サーバーとリソースサーバーを分けていないとか、、
けっこう複雑な仕組みであるので、ざっくりとしたものにしておきます。
現在勉強中です。
詳しくは、こちらの記事を参考に。
OAuth アクセストークンの実装に関する考察
おわりに
仕組みをおおまかに理解したので、アウトプットとしてまとめました。
適切な表現でない部分も多々あると思います。
OAuthはやりとりが多いものであるのに難しく書かれたものばかりでイメージがわかず、最初理解に苦しんだので、同じ気持ちの誰かの役に立てばいいなと思ってます。