- 追加された行はこの色です。
- 削除された行はこの色です。
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-戻る
--[[OAuth 2.0 拡張]]
--[[UserAgentでOAuth2のTokenを取得するベスト・プラクティス]]
-[[戻る>OAuth PKCE]]
* 目次 [#d22d27a9]
#contents
*概要 [#aa36bb43]
*詳細 [#y3abccab]
*参照 [#d8a650bd]
*概要 [#v6a8d036]
[[SPA>Single-page application]]で[[PKCE>OAuth PKCE]]する場合のプロファイル。
*詳細 [#n4168d13]
**特徴 [#x41303e1]
-カスタムURLスキームを使用しない「response_mode=fragment」で認可リクエストを行う。
-バックエンドからclient_secret付きでTokenリクエストにするものと思っていたが、
--[[以下>#jf4fadcd]]を確認すると、client_secretは不要らしい([[SPA>Single-page application]]上からTokenリクエスト可能)。
--一方で、[[Hybrid Flow>OpenID Connect#l565139a]]のcodeは
バックエンドからclient_secret付きでTokenリクエスト(code_verifier無いから)。
**実装 [#gd7ca851]
従って、基本的には、まんま[[PKCE>OAuth PKCE]]を[[SPA>Single-page application]]から実装すれば良い。
***認証 [#jad079a9]
-前述の[[特徴>#x41303e1]]の通り、client_secretは不要。
-JavaScriptから基本認証の付加は難しいので、~
AuthZ(N)側が [[client_secret_post>OpenID Connect - クライアント認証#b718e26d]] をサポートしていると吉。~
(そもそも、client_secret無しの基本認証ってのもアレ)
***フロー [#o3d5f3a3]
基本的に、ネイティブ・アプリケーションと同様に、~
フロントエンド・ホスト側のエンドポインドは利用しなくていい。
-認可リクエストはフロントエンド・ホストからリダイレクトで開始するのだと考えていた。
--しかし、Routerを定義したSPAでは、自サイトにHTTPリクエストが飛ばず、
--ネイティブ・アプリケーションと同様に、Public Clientから直接リクエストした。
-リダイレクト・エンドポイントを経由してCodeを受け取るのだと考えていたが、
--しかし、Routerを定義したSPAでは、自サイトにHTTPリクエストが飛ばず、
--カスタムURLスキームと同様、直接、Public Clientに戻ってCodeを取得する。
※ Router(URLによるページ遷移)を定義した[[SPA>Single-page application]]では、~
自サイトにHTTPリクエストが飛ばなくなる。と言うのがポイント。
*参考 [#jf4fadcd]
-Okta Developer~
--Implement the OAuth 2.0 Authorization Code with PKCE Flow~
https://developer.okta.com/blog/2019/08/22/okta-authjs-pkce
---Replace Implicit Flow with PKCE~
https://developer.okta.com/blog/2019/08/22/okta-authjs-pkce#replace-implicit-flow-with-pkce
----
Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]