はじめに
以下の記事でも言っているようにOAuth2.0の認可サーバーを作ろうとしています。
OAuth2.0の認可サーバーを理解する〜動作理解編〜
OAuth2.0の認可サーバーを作るにあたって、世の中のOAuth2.0の認可サーバーはどのような動きをしているのかを調査するため、認可エンドポイントがどのようになっているか考察してみようと思います。
今回はMicrosoft Azureにサインインする際に使用するOAuth2.0実装を見ていきたいと思います。
とは言ってもほとんどOAuth2.0フレームワーク上で実装されるOpenID Connectの仕様に紐づく箇所が多いので、関連仕様も出しながら考察していきたいと思います。
認可エンドポイントのパス
RFC6749の例とMicrosoft Azureのパスを比べてみましょう。
| 認可サーバー | パス |
|---|---|
| RFC6749の例 | /authorize |
| Microsoft Azure | /common/oauth2/authorize |
Microsoft Azure側のパスは「/authorize」までの間にいくらかパスがあるみたいです。
「/common」はログインするテナント先が独立したテナント（共通テナント）であることを表すようですね。参考
「/oauth2」はOAuth2.0のアプリケーションを表すパスなのだと推測できます。
そう考えると例とほぼ同じ内容だと言えると思います。
リクエストパラメータ
次はリクエストパラメータを見ていきましょう。
| パラメータ | 値 |
|---|---|
| client_id | 23523755-3a2b-41ca-9315-f81f3f566a95 |
| response_mode | form_post |
| response_type | id_token+code |
| scope | openid email profile |
| state | OpenIdConnect.AuthenticationProperties=英数字記号混合ランダム文字列 |
| nonce | 数字.英数字混合ランダム文字列 |
| redirect_uri | https://azure.microsoft.com/ |
| post_logout_redirect_uri | https://azure.microsoft.com |
パラメータを１つずつ見てきます。
client_idはRFC6749で定義されているパラメータで、クライアントアプリケーションを一意に特定するIDです。今回の例ではMicrosoft Azure（具体的にはAzure Portal）がMicrosoftが提供するOAuth2.0認可サーバーの１クライアントとして動いていると想定できます。
response_modeは「OpenID Foundation」の「OAuth 2.0 Multiple Response Type Encoding Practices」で定義された、認可エンドポイントからクライアントアプリケーションへ値を渡す方法を指定するものです。「form_post」の値は、同団体が策定した「OAuth 2.0 Form Post Response Mode」の中で定義されており、「redirect_uri」にPOSTメソッドで値を渡すことを表します。今回はAzure Portalのトップページである https://azure.microsoft.com/ にPOSTメソッドで情報を渡すようです。
response_typeはRFC6749で定義されているパラメータで、認可エンドポイントからクライアントアプリケーションに渡す情報が変わります。ちょっとしたところですが、「OpenID Connect Core 1.0」では複数のresponse_typeを指定する際は「 」（半角スペース）で値を区切るところを、Microsoftさんは「+」で区切っているようです。
scopeはRFC6749で定義されているパラメータで、クライアントアプリケーションがアクセスするリソースサーバー上のリソースを示すものです。指定されている値は「OpenID Connect Core 1.0」で指定している値で、メールアドレスとプロフィールにアクセスできるすることを表す値です。
stateはRFC6749で定義されているパラメータで、クロスサイトリクエストフォージェリを防ぐためのリクエストごとに一意になる値です。他の値とは違ってこれ自体が情報を持っているわけではなく、セキュリティを強化する用途で使用されます。Azure Portalにログインする時の値だとプレフィックスとして「OpenIdConnect.AuthenticationProperties=」がつくように見えます。
nonceは「OpenID Connect Core 1.0」で定義されているリプレイアタックを防ぐための値のようです。この値もstateと同じようにセキュリティを強化する用途で使用されます。stateは通信自体の整合性を担保するのに対し、nonceはID Tokenの偽造に対して効果を発揮します。
redirect_uriはRFC6749で定義されているパラメータで、認可エンドポイントによる処理が終わった後にクライアントアプリケーションに操作を返すのに使用されます。
post_logout_redirect_uriは今のところドラフト段階の値みたいですね。「OpenID Connect Session Management 1.0」で定義されていて、認可サーバからログアウト時に遷移するURLを指定できるものみたいです。
まとめ
基本的には仕様から大きく外れているような箇所はありませんでした。
むしろほぼ仕様どおり実装されているのを見るとさすがOpenID Foundationのスポンサーさんだなあと思いました。
そして実際に実装されている例を見るととても理解が進んで面白かったです。
本当は値のValidationやエラーのハンドラにも触れたかったのですが、パワーがとても必要だったのでやめちゃいました。
nonceの検証方法などまだ具体的に把握しきれていない箇所があったりするので、実装するにあたっては理解を深めていきたいです。
参考文献
OpenID Foundation https://openid.net/developers/specs/