「マイクロソフト系技術情報 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、共に、この規格の導入を検討してイイ。
 
参考  †
仕様  †
スマホのOAuth PKCE認証フローは複雑で忘れ易く、
開発環境の構築時も「どうするんだっけ?」と一苦労するのでメモ。
- OAuth PKCEの認可リクエスト ~ 認可レスポンスで、Client(UserAgent?)はcodeを入手
 
- codeをClient(Server)にpostしてアクセストークン・リクエスト(PKCE)
 
- Client(UserAgent?)は、Client(Server)経由でaccess_tokenを受け取り、Resource Serverにリソースをリクエスト
 
※ よくよく見ると、Cordovaと外部ブラウザでSessionが違うので、
 stateもcode_challengeもCordova側で生成・保持しておく必要がある。
Tags: :認証基盤, :クレームベース認証, :OAuth