前回に続き、OAuth2 / OpenID Connect課題解決 備忘録の第4回です。

＜以前の投稿（第2回）で認証対象がユーザだった場合。＞

　以前の投稿では、 「OAuth2 / OpenID Connect」による認証を使用した「リソース アクセス ストラテジ」としては変則的な「サーバ信頼セキュリティ モデル」について説明をしましたが、今回は「OAuth2 / OpenID Connect」で本命となる「ベース クライアント セキュリティ モデル」のフローの以下の選択肢について説明します。

　私が洗い出した限りですが、「OAuth2 / OpenID Connect」では、ザックリ、以下のユースケースに対応するフローを選択することが出来ると思います。

---

＜ (1) サーバー サイドからリソース アクセスする場合＞

　OAuth2の最も基本的なフローである「Authorization Codeグラント種別」では、サーバーがAccess tokenを取得してリソース アクセスすることができるようになります。

＜ (2) クライアント サイドからリソース アクセスする場合＞

　「Implicitグラント種別」では、WebアプリケーションやSPAアプリケーションのUserAgent（WWWブラウザ や WebView）がAccess tokenを取得してリソース アクセスすることができるようになります。この方式には、前述の「Authorization Codeグラント種別」と比べて、UserAgentにAccessトークンが露見しやすいという問題があります。

＜ (3) 認証用の利用の不安を払拭したい場合＞

　Internetのcross domain環境下で使用されるOAuth2を安全に使用するには様々は考慮が必要でしたが、「OpenID Connect」では、これらを仕様に盛り込んで、認証専用の用途でも、よりセキュアに使用できるようになっています。認証専用のIDトークンをJWTというアサーション形式で発行するのが特徴です。前述のフローと≒の "Authorization Code Flow" と "Implicit Flow"に加え、後述の "Hybrid Flow" をサポートしています。

＜ (4) クライアントとサーバーからリソース アクセスする場合＞

　「OpenID Connect の Hybrid Flow」では、クライアントとサーバーにトークンを供給します。クライアントとサーバーでリソース アクセスのスコープを変更する（クライアンとのスコープをサーバーのスコープより絞る）などして、よりセキュアに実装することができます。

＜ (5) スマホからリソース アクセスする場合＞

　「OAuth PKCE」では、「カスタムURLスキームの上書き攻撃」などの、「認可コード横取り攻撃 (authorization code interception attack) 」へ備えるために、"code_verifier"を生成し、"code_challenge"を認可リクエストに付与します。また、これにより、Publicクライアントであるスマホ・アプリケーション側に"client_secret"を持たせる必要の無い、セキュアな方式になっています。

＜ (6) 金融分野におけるAPIのセキュリティ水準を確保したい場合＞

　現在、「Financial API (FAPI)」という、金融分野におけるAPIのセキュリティ水準を確保するプロファイルが策定中です。「Part１は参照系」、「Part2は更新系」のプロファイルとなっており、「OAuth2 / OpenID Connect」の様々な拡張・オプション仕様が使用されます。