OAuth2.0とは
トークンの取得方法とトークンの使用方法に関することである
OAuthの特徴
- システムをまたいで認可を行えるようにする認可プロトコルである
- パスワードの共有のようなアンチ・パターンを委譲プロトコルに置き換えておりより安全で勝つより使いやすいものになっている。
- OAuthは自信が扱う問題の範囲を限定し、その問題を適切に解決することに専念しており、そのことがOAuthをさらに大きなセキュリティの枠組みの中で役割を果たすための一つの要素となっている
OAuthダンス ~OAuthの構成要素間の相互作用~
用語確認
-
トランザクション
複数の処理を一つのまとまりとして実行し、そのすべてが確実に完了するか、全く実行されないかという一貫性を保証する仕組みです。特にデータベースや分散システムで用いられる概念であり、データの整合性や信頼性を守るために重要な役割を果たします。
OAuthのトランザクションのイベントの流れ
- リソース所有者はクライアントにリソース所有者の代わりとしてふるまって欲しいことを支持する
- クライアントは認可サーバーにリクエストをし、そこでリソース所有者にクライアントを認可するかどうかの判断を行わせる
- リソース所有者はクライアントを認可する
- クライアントは認可サーバーからトークンを受け取る
- クライアントは保護対象リソースにトークンを提示する
OAuthのしくみにおける4つのアクターとなる構成要素+α
クライアント(例:Webアプリケーション、ネイティブアプリケーション、ブラウザ内のJavaScriptアプリケーション)
- ソフトウェアのことであり、リソース所有者の代わりとして保護対象リソースへのアクセスを試みるもの。
- OAuthのしくみの中で最もシンプルな構成要素となっており、その責務は主に認可サーバーからトークンを取得することおよびそのトークンを保護対象リソースで使うことになる。
保護対象リソース
- HTTPサーバーから提供されていて、そのリソースにアクセスするにはOAuthのトークンが必要になる
- OAuthの構造において、保護対象リソースはトークンを信頼するかどうかの最終的な決定権を持つ存在になる
リソース所有者(ユーザー)
- クライアントにアクセス権を委譲する権限を持つ存在
認可サーバー
- OAuthのしくみの中心的な役割を担うHTTPサーバーのこと
- 認可サーバーはリソース所有者とクライアントの認証を行い、リソース所有者にクライアントを認可するための仕組みを提供しトークンをクライアントに発行するもの
アクセス・トークン
- 表すものはクライアントによってリクエストされたアクセス権、クライアントを認可したリソース所有者、そして認可処理を経て得られる権限を組み合わせたもの
- 認可サーバーはトークンを発行、保護対象リソースはトークンを検証するためトークン自体について何を表しているか理解する必要があるが、クライアントはトークンについて知る必要が全くないためクライアントはシンプルな構造を保つことができている
スコープ
- 保護対象リソースでの権限を表すものである
- 例:写真読み込み、メタデータ読み込みなどの具体的な保護対象リソースでの権限
リフレッシュトークン
- リフレッシュ・トークンは認可サーバーによってクライアントに発行され保護対象リソースには送られない
- クライアントはリフレッシュ・トークンを使ってリソース所有者を巻き込むことなく新しいアクセス・トークンをリクエストすることができる
認可付与
- 認可付与とはOAuthのクライアントに保護対象リソースへのアクセス権をOAuthのプロトコルを介して与えるための手段であり、そのことに成功すればクライアントはトークンを取得することになる
OAuthの構成要素間のやり取り
- OAuthはHTTPベースのプロトコルである
- OAuthでのやり取りは常に単純なHTTPのリクエストとレスポンスを介して行われるというわけではない
バック・チャネル・コミュニケーション
- クライアントと認可サーバー、クライアントと保護対象リソース間でのコミュニケーションのこと
フロント・チャネル・コミュニケーション
- 直接連携することはなく、Webブラウザを介したHTTPリダイレクトを使った間接的に連携する
- コミュニケーションの方法はURLにパラメータをつけてパラメータを読み込むように伝えることで行っている