OSS Consortium


 

日本語 | English

開発基盤部会 Blog

開発基盤部会 Blog >> Article details

2018/05/21

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

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

 今回のテーマは、
  「何故かエンプラで採用の多い、Client Credentialsグラント種別」
 です。

 エンタープライズでOAuth2 / OpenID Connect認証の相談に乗っていると、結果として、「Client Credentialsグラント種別」を使用するというジャッジになるケースが多いです。この理由は、ユーザの認証自体は他のSSO認証基盤などで処理をしており、バックエンドのWebAPIの認証にのみOAuth2を使いたいというケースが多いためのようです。

 この場合、WebAPIの機能としては、ユーザを識別しますが、OAuth2で認証しているのはサーバーなので、「リソース アクセス ストラテジ」としては「サーバ信頼セキュリティ モデル」に該当し、(基本4フローと呼ばれる)ベーシックなOAuth2中のフローでは、「Client Credentialsグラント種別」というマイナーなフローのみが適合します。

 しかし、このフローは、サーバーの ”client_id” と ”client_secret” による「基本認証」を用いて ”access_token” を発行して貰うという非常に簡単なモノで、WebAPI側で「ベース クライアント セキュリティ モデル」と「サーバ信頼セキュリティ モデル」の2つの 「リソース アクセス ストラテジ」に対応するには、ユーザ情報を "access_token" から取得するか?WebAPIの引数などから別途取得するか?の検討と独自実装が必要になるので少し大変になります。

 なので、OAuth2の「ベース クライアント セキュリティ モデル」のサポートが不要ということであれば、各種のペイメント・サービス・プロバイダなどのWebAPIも「基本認証」を使用していたりするので、そこは、割り切って「基本認証」としてしまい、OAuth2に拘る必要もないかもしれません。また、「基本認証」や「Client Credentialsグラント種別」ではセキュリティ的に心配だという話であるなら、GoogleやMicrosoftのサービスでも使用されている「JWT bearer token authorizationグラント種別」という公開鍵暗号方式を使用する方式がイイかと思います。

 今回の話を要約すると、エンタープライズでWebAPIにOAuth2を使用したいという場合は、認証すべきは、ユーザーですか?サーバーですか?という 「リソース アクセス ストラテジ」(要件) をしっかりヒアリングして、システムとしての認証の対象がサーバーである場合は、「セキュリティ要件」と、「使用しているIdP/StSの機能レベル」を考慮したうえで、「基本認証」、 「Client Credentialsグラント種別」、「JWT bearer token authorizationグラント種別」の中から選択するとイイと言う事になります。
09:00 | Impressed! | Voted(0) | Comment(0) | ご報告