「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
UserAgent?でOAuth2のTokenを取得するベスト・プラクティス
(UserAgent?から、直接、Resource ServerのWebAPIにアクセスする)
詳細 †
SPA †
SPA : Single Page Application
Implicitが使用できる。 †
Hybridでセキュリティが強化される。 †
- 入手したcodeはClientのServer側にポストして使用する。
※ Publicクライアントにclient_id、client_secretを持たせてはダメなので。
スマホ †
前提条件 †
- codeとtokenが、「Private-Use URL Scheme上書き攻撃」などから保護されない可能性がある。
Implicitは使用できない。 †
- これにより「Private-Use URL Scheme上書き攻撃」などから保護される。
- 入手したcodeはClientのServer側にポストしてアクセストークン・リクエストする。
※ Publicクライアントにclient_id、client_secretを持たせてはダメなので。
response_typeにcodeやtokenを利用できる可能性。 †
- これを利用することで、codeとtokenが完全に保護されるのであれば、
response_typeにcodeやtokenを利用することもできるかも。
- 金融向け規格なので、前述よりさらにセキュリティ・レベルが強化される。
- 現時点では、まだドラフト段階だが、スマホ、SPA、共に、この規格の導入を検討してイイ。
参考 †
仕様 †
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: :認証基盤, :クレームベース認証, :OAuth