はじめに
この記事ではAuth0と連携済みのSingle Web Applicationを利用してTokenベース認証の動作を確認しています。
環境
環境と認証・認可のフロー概要です。
この記事ではImplicit Flowを使った実装を行っています。本番環境ではより安全なAuthorization Code Flow with PKCEを推奨します。
参考
- ブラウザ : Chrome
- クライアント : Single Page Web Applications
- 認可サーバ : Auth0
- リソースサーバ : AWS API Gateway
動作確認
ChromeからSPA1にアクセスしてユーザをサインアップします。
サインアップが成功するとAuth0からSPAにID Token, Access Tokenが払い出されて、SSO用にChromeのLocal Storageに各々のTokenが保存されます。
Chromeのデベロッパーツールを開いてLocal Storageに保存されたID Token, Access Tokenを確認します。
この記事では説明をわかり易くするためにChromeのLocal StorageにToken保存しています。本番環境ではSecure Cookieに保存してユーザが読めないようにして下さい。Local Storageには絶対に保存しないで下さい。
Chromeで新しいタブを開いてSPA1にアクセスします。
ChromeのLocal Storageに保存されているID Tokenを確認してSSOできました。
Chromeで新しタブを開いてSPA2にアクセスします。認可サーバから払い出されたLogin Sessionが保存されていることがわかります。Loginを押すとLogin Sessionを認可サーバに渡してID Token, Access Tokenを取得しSSOできました。
Chrome以外のブラウザでSPAにアクセスしてデベロッパーツールでLocal Storageを確認します。Auth0から払い出されたLogin Sessionを持っていないためSSOできません。
おわりに
Tokenベースの認証は、認可サーバが払い出したTokenをクライアント側に持たせることができるため、一度認可サーバに認証された後はTokenが有効な間はユーザエージェントとクライアント間で認証を完結することができます。なお、Auth0 SDK for Single Page Applicationsは認可サーバが持っているSession情報をチェックして、クライアント側が保持しているTokenが無効になっている場合はRefresh Tokenを認可サーバのToken End Pointに送信して新しいTokenをシームレスに取得しています。クライアントから認可サーバの認可エンドポイントを呼び出す回数を減らせるのでシステム全体のスループットも上がりますね。
参考
Cookies vs. Tokens: The Definitive Guide
Security Best Practices for Managing API Access Tokens