.NET 開発基盤部会 Blog

.NET 開発基盤部会 Blog >> 記事詳細

2018/06/11

OAuth2 / OpenID Connect課題解決 備忘録 4

Tweet ThisSend to Facebook | by:nishino
前回に続き、OAuth2 / OpenID Connect課題解決 備忘録の第4回です。

以前の投稿(第2回)で認証対象がユーザだった場合。>

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

 私が洗い出した限りですが、 「OAuth2 / OpenID Connect」では、ザックリ、以下のユースケースに対応するフローを選択することが出来ると思います。
  1. サーバー サイドからリソース アクセスする場合
  2. クライアント サイドからリソース アクセスする場合
  3. 認証用の利用の不安を払拭したい場合
  4. クライアントとサーバーからリソース アクセスする場合
  5. スマホからリソース アクセスする場合
  6. 金融分野におけるAPIのセキュリティ水準を確保したい場合


< (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のセキュリティ水準を確保するプロファイルが策定中です。「Part1は参照系」、「Part2は更新系」のプロファイルとなっており、「OAuth2 / OpenID Connect」の様々な拡張・オプション仕様が使用されます。
09:00 | 投票する | 投票数(0) | コメント(0)