SPA（Single Page Application）とWeb APIで構成されるWebアプリケーションにOIDC（OpenID Connect）認証フローを導入する場合、主に Authorization Code Flow with PKCE (Proof Key for Code Exchange) を採用するのが一般的で、推奨されます。
なぜ Authorization Code Flow with PKCE が適しているのか？
SPAはブラウザで直接実行されるため、クライアントシークレットを安全に保管できないという制約があります。従来のAuthorization Code Flowではクライアントシークレットを必要とするため、SPAのようにシークレットを安全に保持できないアプリケーションには不適切です。PKCEはこの問題を解決するために追加された仕組みで、クライアントシークレットを不要にし、代わりに「コードチャレンジ」と「コードバリファイア」という値を利用して認可コードの盗聴や悪用を防ぎます。
Authorization Code Flow with PKCE の流れ
-
リクエストの生成：
SPAは認可サーバーに認証リクエストを送信します。このとき、ランダムなコードバリファイアを生成し、それをハッシュ化した「コードチャレンジ」を認可サーバーに送ります。 -
認証と認可コードの取得：
ユーザーが認証されると、認可サーバーはSPAに「認可コード」を返します。この段階ではアクセストークンは発行されません。 -
アクセストークンの取得：
SPAは、取得した認可コードとコードバリファイアを使用して認可サーバーにアクセストークンをリクエストします。認可サーバーは、コードチャレンジとコードバリファイアを比較し、検証が成功すればアクセストークンとIDトークンを返します。 -
トークンの利用：
SPAは、取得したアクセストークンを用いてWeb APIにアクセスし、認証されたリクエストを送信します。IDトークンは、ユーザー情報を含んでおり、ユーザー認証に関する情報を含んでいます。
このフローのメリット
- 安全性が高い：PKCEにより、認可コードの盗聴や改ざんのリスクを減らし、より安全にSPAで認証を実行できます。
- クライアントシークレットが不要：SPAはブラウザ上で実行されるため、サーバーサイドと異なりシークレット情報を保持できないため、PKCEを利用することで安全に認証フローを行えます。
- OAuth 2.1に準拠：最新のOAuth仕様にも適合しており、標準化された安全なフローです。
注意点
- PKCE対応の認可サーバーが必要ですが、主要な認証プロバイダー（Auth0、AWS Cognito、Azure AD B2C、Oktaなど）はPKCEをサポートしています。
- ブラウザのセキュリティ設定やフロントエンドフレームワークに適した実装が必要です。
結論として、SPAとWeb APIで構成されたWebアプリケーションにOIDCを導入する際は、Authorization Code Flow with PKCE を選択するのがベストプラクティスです。