SPAはOIDCの暗黙的フローまたは認証コードフローを使用する必要がありますか？
OpenID Connect（OIDC）を使用してSSO機能のためにKeycloakを活用する新しいAngular SPAを開発しています。このアプリは現在、暗黙フローを使用して、Keycloak経由で短期間のアクセストークンを取得するように設計されていますJSアダプター。
ただし、最近、 ietfメーリングリスト にいくつかの電子メールが表示され、アクセストークンがブラウザの履歴に表示されるというセキュリティ上の問題や、ログファイル（SSL終了/検査が実施されている場合など）.
ATがログファイルのどこかに表示されることによるセキュリティ上の懸念を理解しています。しかし、Auth Codeフローをより安全であると見なす方法、またはその理由を理解していません暗黙的なフローよりも優先されます。ブラウザ/ SPAに更新トークンがあると、ログファイルに短命のATがあるよりもセキュリティリスクが高くなりますか？
SPAのために今日使用するために推奨されるメカニズムは何ですか？推奨されるアプローチはありますか？
OPからの素晴らしい研究努力！賛成。したがって、クロスポストされた SOでの質問 からすでに回答を得ています。その上、ここでは、元のOAuth2 RFC 6749に基づいて、質問の1つのステートメントを明確にしようとしています。
ATがログファイルのどこかに表示されることによるセキュリティ上の懸念を理解しています。しかし、Auth Codeフローをより安全であると見なす方法、またはその理由を理解していません暗黙的なフローよりも優先されます。ブラウザ/ SPAに更新トークンがあると、ログファイルに短命のATがあるよりもセキュリティリスクが高くなりますか？
技術的には、認証コードフローは必ずしも更新トークン（RT）が常に返されることを意味するわけではありません。 OAuth2 RFCセクション4.1.4 に従って、RT応答はオプションです。クライアントは要求しないことを選択でき、サーバーは発行しないことを選択できます。
Implicit Grantの懸念は、単なるログ記録ではありません。 OAuth2 RFCセクション4.2 言及：
（暗黙的な付与では）アクセストークンはリダイレクトURIにエンコードされるため、同じデバイス上にあるリソース所有者や他のアプリケーションに公開される可能性があります。
逆に、Auth Codeの付与では、この懸念はありません。認証コードとトークンの引き換えは、SPAと認証サーバーの間で行われ、通常は通常のブラウザー履歴に痕跡を残しません。
現在推奨されているアプローチは、認証コードとPKCE（コード交換の証明キー）を使用することです。
懸念される脅威は、URLからアクセストークンを漏らすことです。URLは機密情報を配置するのに適した場所ではなく、URLが漏えいする可能性があるいくつかの方法があります。機密クライアントがコードフローを使用する場合、攻撃者はクライアントシークレットを知らずに認証コードを使用できないため、URLからの認証コードのリークは大きな問題ではありませんが、パブリッククライアントでは、攻撃者はクライアントシークレットを知っているため、トークン交換を行います。ステップはほとんど保護を提供しません。暗黙的なフローは、リクエストの一部としてWebサーバーに送信されないハッシュフラグメントにアクセストークンを入れることでこれを軽減し、PKCEなしでコードフローを使用するよりも安全にします。また、OIDCが設計された当時、CORSはそれほど広くサポートされていなかったため、SPAでのコードフローの使用には、セキュリティ上の懸念がなくてもいくつかの課題がありました。これは、暗黙フローが含まれている理由を説明するのに役立つと思います。オリジナルのOIDC仕様。
PKCEは、認証の試行ごとにランダムな文字列（コード検証と呼ばれる）を生成し、「暗号化」を使用して、このランダムな文字列を知っている呼び出し元のみがトークン交換を完了できるようにし、攻撃者が知っている場合でも認証コードが役に立たないようにします。クライアントシークレット。
参照：