「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
UserAgent?（SPAやスマホ）でOAuth2のTokenを取得するベスト・プラクティス
（UserAgent?から、直接、Resource ServerのWebAPIにアクセスする）
詳細 †
SPA †
SPA : Single Page Application
Implicitが使用できる。 †
...が、最近、
が、公式に非推奨になったらしい。
- 入手したcodeはClientのServer側にポストして使用する。
※ Publicクライアントにclient_id、client_secretを持たせてはダメなので。
※ Token Bindingの雲行きが怪しくなっているので、
PKCE＋Fragment みたいな方式はアリかもしれない。
- SPAをターゲットとして仕様が作成されている。
- 名前の通り、アプリケーション・レイヤで、記名式切符を発行することができる。
- これにより、SPAから直接Tokenエンドポイントにリクエストすることができる。
スマホ †
前提条件 †
- codeとtokenが、「Private-Use URL Scheme上書き攻撃」などから保護されない可能性がある。
Implicitは使用できない。 †
- これにより「Private-Use URL Scheme上書き攻撃」などから保護される。
- 入手したcodeはClientのServer側にポストしてアクセストークン・リクエストする。
※ Publicクライアントにclient_id、client_secretを持たせてはダメなので。
Token Binding時代の到来。
- 金融向け規格なので、前述よりさらにセキュリティ・レベルが強化される。
- 現時点では、まだドラフト段階だが、スマホ、SPA、共に、この規格の導入を検討してイイ。
- F-API 1 / 2 共に、Confidential Client / Public Clientのプロファイルを持っている。
- このうち、スマホ / SPA、は、Public Clientのプロファイルを適用する。
S256のPKCE
...未定...
サマリ †
現状では、
| # | 方式 | Flow | 認証（BackendからのResourceアクセス） | 認可（FrontendからのResourceアクセス） |
| 1 | Web Forms / MVC | | |
| 1-1 | ・ | Authorization Code Flow | ○ | － |
| 2 | SPA | | |
| 2-1 | ・ | Authorization Code Flow | ○ | △ |
| 2-2 | ・ | Implicit Flow | △ | ○ |
| 2-3 | ・ | Hybrid Flow | ○ | ○ |
| 2-4 | ・ | PKCE + Fragment | ○ | ○ |
| 3 | Native | | |
| 3-1 | ・ | PKCE | ○ | ○ |
解説 †
- 2-1
SPAとAuthorization Code Flowはミスマッチ。
- Backendで認証可能
- FrontendにAccessToken?が渡らない（Hiddenに入れて渡すなどは可能）。
- 2-2
Authorization Code Flowより適合した方式。
- FrontendにAccessToken?が渡る。
- Backendの認証が出来ない（AccessToken?をBackendにPOSTすれば可能）。
- 2-3
上記の2-1, 2-2の問題を解消した方式。
- FrontendにAccessToken?が渡る。
- BackendにcodeをPOSTし、Backendが、AccessToken? Requestする。
- 2-4
上記の2-3よりセキュアにした方式。
- BackendにcodeをPOSTし、Backendが、AccessToken? Requestする。
- FrontendからのResourceServer?アクセスは
- Backend経由とするか、
- codeをPOSTした際の戻り値としてAccessToken?を受け取る。
参考 †
仕様 †
OSSコンソーシアム †
スマホのOAuth PKCE認証フローは複雑で忘れ易く、
開発環境の構築時も「どうするんだっけ？」と一苦労するのでメモ。
Client（UserAgent?）は、
- OAuth PKCEの認可リクエスト ～ 認可レスポンスで、codeを入手
- codeをClient（Server）にpostしてアクセストークン・リクエスト（PKCE）
- Client（Server）経由でaccess_tokenを受け取り、
- access_tokenを使用してResource Serverにリソースをリクエスト
※ よくよく見ると、Cordovaと外部ブラウザでSessionが違うので、
stateもcode_verifierもCordova側で生成・保持しておく必要がある。
※ また、code_challengeは、Server側でcode_verifierを受け取り、
ハッシュ関数（plain or S256）を選択して生成する必要がある。
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
