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

目次

概要

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

詳細

SPA

SPA : Single Page Application

Implicitが使用できる。

...が、最近、

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

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

  • codeやtokenのscope(認可された権限)を変える。
    Financial API (FAPI)では、token:参照系、code:更新系などとなっている。
  • 入手したcodeはClientのServer側にポストして使用する。
    ※ Publicクライアントにclient_id、client_secretを持たせてはダメなので。

Financial API (FAPI)も策定中。

Token Bindingの雲行きが怪しくなっているので、
 PKCE+Fragment みたいな方式はアリかもしれない。

OAuth2.0 DPoP

  • SPAをターゲットとして仕様が作成されている。
  • 名前の通り、アプリケーション・レイヤで、記名式切符を発行することができる。
  • これにより、SPAから直接Tokenエンドポイントにリクエストすることができる。

スマホ

前提条件

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

Implicitは使用できない。

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

S256のPKCE

FAPI Part 2

...未定...

サマリ

現状では、

#方式Flow認証(BackendからのResourceアクセス)認可(FrontendからのResourceアクセス)
1Web Forms / MVC
1-1Authorization Code Flow
2SPA
2-1Authorization Code Flow
2-2Implicit Flow
2-3Hybrid Flow
2-4PKCE + Fragment
3Native
3-1PKCE

解説

  • 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コンソーシアム

OAuth PKCE利用時の構成図

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

Client(UserAgent?)は、

  1. OAuth PKCEの認可リクエスト ~ 認可レスポンスで、codeを入手
  2. codeをClient(Server)にpostしてアクセストークン・リクエスト(PKCE
  3. Client(Server)経由でaccess_tokenを受け取り、
  4. access_tokenを使用してResource Serverにリソースをリクエスト
OAuth PKCE利用時の構成図

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

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


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


添付ファイル: filePKCE Flow.jpg 133件 [詳細]

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2019-04-19 (金) 10:55:19 (19h)