「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- OpenID Foundationが後援する各Native App環境をサポートするSDK。
- iOS, macOS
- Android
- Native JS
- Native AppへのWebView?埋め込みを遠ざけ、代わりに以下の使用を主張する
- 外部エージェント（システムブラウザ）
- アプリ内ブラウザタブ（SFAuthenticationSession?やカスタムタブ）
詳細 †
基本的な処理 †
以下のような処理を実装できる。
- 認証・認可を要求する
- 認証・認可に使用するサーバーの情報を取得する。
- アプリ内ブラウザタブを使って認証・認可のリクエストを行なう。
- 認証・認可の結果を受け取る
- カスタムURIスキームへのリダイレクトを介して認証・認可結果を受け取る。
- サーバーから Access Token、Refresh Tokenを取得する。
- Access Token、Refresh Tokenを永続データとして保管する
- 一度サインインを完了した後はその状態を維持するため、
Access Token、Refresh Tokenを永続データとして保管する。
- Token漏洩リスクを軽減するため、暗号化を行なうことが望ましい。
- Access Tokenを更新する
- Access Tokenの有効期限が切れている場合は、
Refresh Tokenを使ってサーバーから新しいAccess Tokenを取得する。
- バックエンドAPIにアクセスする
Access Tokenを Authorization ヘッダに付けてAPIにアクセスする。
- Access Tokenを無効化する
- Access Token、Refresh Tokenをアプリ内から破棄する。
- この時、サーバー側でも無効化することが望ましい（Revocation）。
AppAuth for iOS and macOS †
恐らく、「AppAuth for Android」と同じ。
- 以下フレームワークを使用するアプリケーションで
使用するように設計されているらしい。
- Webアプリ
- Node.js CLIアプリケーション
- Chromeアプリ
- Electronなど
- Native AppとBrowser Appの双方をサポート
Browser App（SPA）向けの場合、ベストプラクティスが異なる。
- Refresh Tokenをフロントチャネルで返さない。
- Access Tokenの永続化場所が、Web Storageなどになる。
OIDC対応 †
JWK処理 †
id_tokenの署名検証に必要になる。
メリット †
仕様への準拠 †
- OAuth / OIDCに準拠してNative Appに外部IDでログインしたいなら、
IdP各社が提供するSDKは使わない。そんなSDKは存在しないため。
- 確かにSQLも些細な方言を混ぜてクロスプラットフォームを困難にしている。
ベストプラクティスへの準拠 †
- AppAuthのメリットは、ベストプラクティスに準拠しているので、
自身のコードの信頼性を主張するのに苦労しなくて済みそう。
- 特に、AppAuth-JSは、
- Hybrid（Native App）
- SPA（Browser App）
の両方のベストプラクティスに対応していそう。
参考 †
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
