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

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

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

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

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

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

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