はじめに
以前、Azure AD B2Cを使ってWebアプリケーションを作成してみた。利用者がサインインする認可の仕組みはOAuth/OpenID Connectを使ったものであったが、そのOAuthについて少し理解を深めてみようと思う。
OAuthにおける認可付与
OAuthとはWebサイトの認可を担うフレームワークで、構成要素は以下４つある。
- リソース所有者（Resource Owner）
その名のとおりリソースの所有者であり、アクセス権をアプリケーションに付与できる人のこと - クライアント（Client）
リソース所有者の代わって、リソースへアクセスするソフトウェアのこと - 認可サーバ（Authorization Server）
リソースを守る仕組みを提供するサーバで、リソース所有者へ認可を要求したり、リソースへアクセスするための一時通行証、アクセストークンを発行したりする - 保護対象リソース（Protected Resource）
リソース所有者がアクセス権をもっているリソースのこと
アクセストークンを要求するにはクライアントはリソース所有者から認可を得る必要があるわけだが、その認可の付与方式には４つある。詳細はRFC 6749の認可の取得をご参照。
- Authorization Code Grant
- Implicit Grant
- Resource Owner Password Credentials Grant
- Client Credentials Grant
今回はすべての構成要素が絡み合うAuthorization Code Grantについて、どのようなやりとりが発生しているかを以下のように主要な通信情報と共に時系列にまとめてみた。
Authorization Code Grantの特徴的な通信フローとして、リダイレクト（302）を利用して接続先を変更している点があげられる。１回目のリダイレクトはリソース所有者をクライアントから認可サーバへ転送させる時で、２回目は逆にリソース所有者を認可サーバからクライアントへ転送させる時である。
今後は他の付与方式やもう少し通信の詳細を調べて追記しておきたい。
