msal.js v2を触る
Download as PPTX, PDF1 like685 views
2020年8月の.NETラボの発表で使用した資料です。 デモで使用したソースコード https://github.com/Takas0522/learn-msal/tree/master/using-msal-v2
![msal.js v2の使い方
- 2.ログイン
• 1.で作成したクライアントを使用してログインする
• これもv1時代と流れは大きくは変わらない
• ポップアップかリダイレクト
• リダイレクトの場合はcallbackを引っ掛ける仕掛けが必要
• V1と違ってcallbackがpromise(handleRedirectPromise)になっている
• ポップアップはPromise返却されるので、awaitかthenで引っ掛ける
• スコープの指定やリダイレクトURIの指定など…
//リダイレクト：asyncなFunctionの中で実行した場合。結果はresに格納される
const res = await this._client.handleRedirectPromise();
this._client.loginRedirect({ scopes: [‘user.read’]});
// ポップアップ：asyncなFunctionの中で実行した場合。結果はresに格納される
const res = await this._client.loginPopup({ scopes: [‘user.read’]});](https://image.slidesharecdn.com/202008dotnetlabmsal-200822083809/85/msal-js-v2-22-320.jpg)
![msal.js v2の使い方
- 3.アカウントの取得
• v1とログインアカウントの取得の仕方が大きく違う
• v1はユーザー取得インターフェースがクライアントにあったが
v2からは消されている。
• ログイン時に返却される情報から抜いてこないといけなくなった
//リダイレクト：asyncなFunctionの中で実行した場合。結果はresに格納されるのでそこから取得
const res = await this._client.handleRedirectPromise();
const account = res.account;
// ポップアップ：asyncなFunctionの中で実行した場合。結果はresに格納されるのでそこから取得
const res = await this._client.loginPopup({ scopes: [‘user.read’]});
const account = res.account;](https://image.slidesharecdn.com/202008dotnetlabmsal-200822083809/85/msal-js-v2-23-320.jpg)
![msal.js v2の使い方
- 4.アクセストークンの取得
• v1と大きく変わらない
• acquireToken(Silent/Redirect/Popup)で取得する
• Silent/Popupは例のごとくPromiseで値返却
• RedirectはhandleRedirectPromiseで
//リダイレクト：asyncなFunctionの中で実行した場合。結果はresに格納されるのでそこから取得
const res = await this._client.handleRedirectPromise();
const accessToken = res.accessToken;
this._client.acquireTokenRedirect({scopes:[‘user.read’]})
// ポップアップ：asyncなFunctionの中で実行した場合。結果はresに格納されるのでそこから取得
const res = this._client.acquireTokenSilent({scopes:[‘user.read’]})
const accessToken = res.accessToken;](https://image.slidesharecdn.com/202008dotnetlabmsal-200822083809/85/msal-js-v2-24-320.jpg)
msal.js v2を触る
- 2. 誰？ @DevTakas Angular / Azure / .NET Core / Azure DevOps / Microsoft Graph Microsoft MVP Office Development(新人)
- 4. おしながき 1. msal.jsとは 2. v2になって変わったこと 3. PKCEについて 4. msal.js v2の使い方 5. まとめ 6. 参考文献
- 5. (そもそも)msal.jsとは • Micro Soft Authentication Library • Azure ADアプリケーションで保護されたWeb APIリソースなど にアクセスするためのトークン取得支援を行うライブラリ • Js以外にも.NET/Java等の様々な言語のライブラリが存在 • AzureAD v2.0エンドポイント対応ライブラリ • V1.0対応エンドポイント対応ライブラリはADAL
- 7. V2のリリース • 2020年7月20日に2.0.0リリース • 現在(2020年8月22日)は2.0.2 • Azure AD B2Cにはまだ使えないらしい • 2.1.0の実装予定の機能なんかももう予告されている • https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-browser
- 10. PKCE - Implicit Flowの問題点 • Proof Key for Code Exchange • AngularやVueといったSPA構成でよく使用される 「暗黙的な許可フロー(Implicit Flow)」 • Implicit Flowには認可コード横取り攻撃が可能な問題が存在 • Implicit Flowは認可コードを用いることで認証なしに アクセストークンを取得するフロー • Implicit Flowは認可コードを用いてアクセストークンを取得する。 悪意のあるアプリケーションは認可コードを横取りすることで 認証なしにアクセストークンを取得することができるようになる
- 12. PKCE - 改善内容 • code_verifier を使用する 1. 認証時 • 下記を付与した通信を行い認可コード取得 • 「code_verifierを変換した値(code_challenge)」 • 「変換方法(code_challenge_method)」 2. アクセストークン取得時 • 「code_verifier」を付与した通信を行う • 認可サーバー上で下記を実施し検証を行う。 • 1.で送付されたcode_challenge_methodで、送付されたcode_verifierを変換 • code_challengeと一致するか検証
- 14. PKCE - Implicit Flowの問題点 code_verifierは？ code_challenge / code_challenge_method Browserインスタンスにしか存在しない
- 15. PKCE -使用されているVerifierについて(msal.js) • initializeAuthorizationCodeRequestがエントリ • ここから追いかければCodeVerifierなどの生成手順がわかる • https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/84a5f5aed0ad1626e6d918fb2ef0393837aac3c6/lib/msal-browser/src/app/PublicClientApplication.ts#L733 • より具体的にはPkceGenerator • 32バイト長のUTF-8ランダム配列 • Code Challenge • SubtleCrypt.Digestを使用しSHA256ハッシュ変換 • SubtleCrypt.Digestは↓参照 • https://developer.mozilla.org/ja/docs/Web/API/SubtleCrypto/digest • RFC7636 Section-4.1のドキュメント準拠な設定 • sessionStorageなどに保存している気配はないので インスタンスのライフサイクルと同等？
- 17. PKCE -使用されているVerifierについて • あくまで「認可コード要求」と「トークン要求」の クライアントが一致しているかを検証するもの • 認可コード要求時点から攻撃されている状態だと 対処できないので注意 • 攻撃用サイトでログイン要求されるとか… • redirect_url/CORSなど基本の設定はしっかり行っておく
- 18. msal.js v2の使い方 - Azure AD アプリケーションの設定 • 認可サーバー(Azure AD)でコード検証フローが発生するので 専用の設定を行う必要がある
- 19. msal.js v2の使い方 - コードの実装 • 基本の流れはv1のときと同じ 1. クライアントインスタンスの生成 2. ログイン 3. アカウント情報の取得 4. アクセストークンの取得
- 20. msal.js v2の使い方 - 1.クライアントインスタンスの生成 • PublicClientApplication インスタンスの生成 • V1同様生成時に使用するADアプリの設定情報が必要 • アプリケーションクライアントID • 特定テナントの指定(任意) • リダイレクトURI(任意) const _client = new PublicClientApplication({ auth: { clientId: ‘xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx’, authority: ‘https://login.microsoftonline.com/<テナントID>/’, redirectUri: ‘<リダイレクトURI>’ } })
- 21. msal.js v2の使い方 - 1.クライアントインスタンスの生成(設定内容) export declare type Configuration = { auth?: { clientId: string – AzureADアプリケーションID(必須) authority?: string – 特定のテナントを使用したい場合に使用 knownAuthorities?: Array<string> - 有効URI配列(B2Cで使用) cloudDiscoveryMetadata?: string – クラウド検出文字列※1 redirectUri?: string – 認証画面後戻ってくるURL。AzureADアプリに設定されているURLでないといけない postLogoutRedirectUri?: string – ログアウト後遷移するURL navigateToLoginRequestUrl?: boolean – リダイレクトページを固定させたいかどうかの指定 }; cache?: { cacheLocation?: string – トークン格納ストレージの選択 ‘sessionStorage/localStorage’ storeAuthStateInCookie?: boolean – 認証状態のCookie格納 }; system?: { loggerOptions?: LoggerOptions – ロギング設定※3 networkClient?: INetworkModule – ネットワークうインタフェースの実装(詳細調査中) windowHashTimeout?: number – ポップアップの待機時間の変更 iframeHashTimeout?: number – iFrameの待機時間の変更 loadFrameTimeout?: number – Frameロード待機時間の変更 }; }; ※1：詳細はhttps://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/performance.md 参照 ※2： https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/09243eb985138d9c39194c3eb84b28cf7a8d8f25/lib/msal-browser/src/request/RedirectRequest.ts 参照 ※3： https://docs.microsoft.com/ja-jp/azure/active-directory/develop/msal-logging?tabs=javascript 参照
- 22. msal.js v2の使い方 - 2.ログイン • 1.で作成したクライアントを使用してログインする • これもv1時代と流れは大きくは変わらない • ポップアップかリダイレクト • リダイレクトの場合はcallbackを引っ掛ける仕掛けが必要 • V1と違ってcallbackがpromise(handleRedirectPromise)になっている • ポップアップはPromise返却されるので、awaitかthenで引っ掛ける • スコープの指定やリダイレクトURIの指定など… //リダイレクト：asyncなFunctionの中で実行した場合。結果はresに格納される const res = await this._client.handleRedirectPromise(); this._client.loginRedirect({ scopes: [‘user.read’]}); // ポップアップ：asyncなFunctionの中で実行した場合。結果はresに格納される const res = await this._client.loginPopup({ scopes: [‘user.read’]});
- 23. msal.js v2の使い方 - 3.アカウントの取得 • v1とログインアカウントの取得の仕方が大きく違う • v1はユーザー取得インターフェースがクライアントにあったが v2からは消されている。 • ログイン時に返却される情報から抜いてこないといけなくなった //リダイレクト：asyncなFunctionの中で実行した場合。結果はresに格納されるのでそこから取得 const res = await this._client.handleRedirectPromise(); const account = res.account; // ポップアップ：asyncなFunctionの中で実行した場合。結果はresに格納されるのでそこから取得 const res = await this._client.loginPopup({ scopes: [‘user.read’]}); const account = res.account;
- 24. msal.js v2の使い方 - 4.アクセストークンの取得 • v1と大きく変わらない • acquireToken(Silent/Redirect/Popup)で取得する • Silent/Popupは例のごとくPromiseで値返却 • RedirectはhandleRedirectPromiseで //リダイレクト：asyncなFunctionの中で実行した場合。結果はresに格納されるのでそこから取得 const res = await this._client.handleRedirectPromise(); const accessToken = res.accessToken; this._client.acquireTokenRedirect({scopes:[‘user.read’]}) // ポップアップ：asyncなFunctionの中で実行した場合。結果はresに格納されるのでそこから取得 const res = this._client.acquireTokenSilent({scopes:[‘user.read’]}) const accessToken = res.accessToken;
- 25. msal.js v2の使い方 - コードの実装 • msal.js を使用したv1との違いを実際に見てみる
- 26. まとめ • msal.js v2がリリースされた • v2の大きな変更はPKCEへの対応が一番大きい • セキュリティ上、PKCE対応を行っておくほうが良い • はよv2に移行しようね • v2の使い方は大きくは変わらない • はよv2に(ry
- 27. 参考文献 • AzureAD/microsoft-authentication-library-for-js • https://github.com/AzureAD/microsoft-authentication-library-for-js • Microsoft ID プラットフォームの認証ライブラリ • https://docs.microsoft.com/ja-jp/azure/active-directory/develop/reference-v2-libraries • Microsoft ID プラットフォームと暗黙的な許可のフロー • https://docs.microsoft.com/ja-jp/azure/active-directory/develop/v2-oauth2-implicit-grant-flow • RFC6749 - 4.1.2. Authorization Response • https://tools.ietf.org/html/rfc6749#section-4.1.2 • RFC7636 • https://tools.ietf.org/html/rfc7636 • OAuth 2.0 Security Best Current Practice • https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.1.2 • PKCE で防げる「認可コード横取り攻撃」とはどのような攻撃か • https://qiita.com/samiii/items/9574d1e237228c718cd6 • Auth0を利用してOAuth 2.0のPKCEを理解する • https://dev.classmethod.jp/articles/oauth-2-0-pkce-by-auth0/