UserAgentでOAuth2のTokenを取得するベスト・プラクティスのバックアップ(No.18) - マイクロソフト系技術情報 Wiki

[ トップ ] [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

戻る

目次 †

概要 †

UserAgent?（SPAやスマホ）でOAuth2のTokenを取得するベスト・プラクティス
（UserAgent?から、直接、Resource ServerのWebAPIにアクセスする）

詳細 †

SPA †

SPA : Single Page Application

Implicitが使用できる。 †

...が、最近、

Implicitグラント種別

Implicit Flow

が、公式に非推奨になったらしい。

Hybrid Flowでセキュリティが強化される。 †

codeやtokenのscope（認可された権限）を変える。
※ Financial API (FAPI)では、token：参照系、code：更新系などとなっている。

入手したcodeはClientのServer側にポストして使用する。
※ Publicクライアントにclient_id、client_secretを持たせてはダメなので。

Financial API (FAPI)も策定中。 †

Token Binding時代の到来。
PKCE＋Token Binding＋Fragment

スマホ †

前提条件 †

（セキュリティ的懸念から）認可リクエストを、外部Webブラウザを経由してのみ行う。
プラットフォームによっては、外部Webブラウザ相当のUXを向上させる仕組みが用意されている。

codeとtokenが、「Private-Use URL Scheme上書き攻撃」などから保護されない可能性がある。

Implicitは使用できない。 †

Implicitグラント種別

Implicit Flow

Hybrid Flowも使用できない。 †

OAuth PKCEを適切に利用する。 †

これにより「Private-Use URL Scheme上書き攻撃」などから保護される。

入手したcodeはClientのServer側にポストしてアクセストークン・リクエストする。
※ Publicクライアントにclient_id、client_secretを持たせてはダメなので。

Financial API (FAPI)も策定中。 †

Token Binding時代の到来。

Financial API (FAPI) †

金融向け規格なので、前述よりさらにセキュリティ・レベルが強化される。
現時点では、まだドラフト段階だが、スマホ、SPA、共に、この規格の導入を検討してイイ。
- F-API 1 / 2 共に、Confidential Client / Public Clientのプロファイルを持っている。
- このうち、スマホ / SPA、は、Public Clientのプロファイルを適用する。

FAPI Part 1 †

FAPI Part 2 †

...未定...

サマリ †

現状では、

図 †

#	方式	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?を受け取る。

参考 †

仕様 †

OAuth 2.0 for Native Apps †

OAuth 2.0 Security Best Current Practice †

OSSコンソーシアム †

UserAgent?でOAuth2のTokenを取得するベスト・プラクティス
https://www.osscons.jp/joavafb1i-537/#_537

Single Sign-On user experience with OAuth PKCE by Open棟梁 and Cordova.
https://www.osscons.jp/jobgbko8n-537/#_537

OAuth PKCE利用時の構成図 †

スマホのOAuth PKCE認証フローは複雑で忘れ易く、
開発環境の構築時も「どうするんだっけ？」と一苦労するのでメモ。

Client（UserAgent?）は、

OAuth PKCEの認可リクエスト～認可レスポンスで、codeを入手
codeをClient（Server）にpostしてアクセストークン・リクエスト（PKCE）
Client（Server）経由でaccess_tokenを受け取り、
access_tokenを使用してResource Serverにリソースをリクエスト

OAuth PKCE利用時の構成図

※ よくよく見ると、Cordovaと外部ブラウザでSessionが違うので、
　stateもcode_verifierもCordova側で生成・保持しておく必要がある。

※ また、code_challengeは、Server側でcode_verifierを受け取り、
ハッシュ関数（plain or S256）を選択して生成する必要がある。

Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth