はじめに
- Azure上で稼働するWebアプリの認証にAuth0を利用する方法を調査
- Azureが提供する組み込み認証の仕組み (Easy Auth) は使わず、Auth0のSDKで制御する方法を検討
- ステートレス・ステートフル認証の実装パターンをそれぞれまとめる
- ソースコード
- サンプル実装のため、参考程度に留めていただけると幸いです
背景
-
下図の構成で、Azure上で稼働しているWebアプリの認証が実現できるか調査していた
-
当初、Static Web Appsの組み込み認証機能 の利用を検討していたが、認証エラーのメッセージによって処理を分けることができないため、不採用
-
エラーメッセージごとの処理を行うために、Auth0 SDKを使用した実装を検討
ステートレス・ステートフル認証
| ステートレス | ステートフル | |
|---|---|---|
| 認証状態 | 保持しない (トークンに認証情報を記録) | サーバ側で保持 |
| 認証の失効 | トークンの有効期限が切れることにより失効 | 即時に可能 |
| サーバ負荷 | 低い | 高い |
- ステートレス認証では、トークンの有効期限が切れるまで認証が失効されない
- アクセストークン (IDトークン) の有効期限はある程度短く設定するべき
- 有効期限が切れるたびにログインし直すのはユーザ負荷が高いので、リフレッシュトークンを併用することで回避する
- リフレッシュトークンは認証サーバ側で状態を管理しているため、有効期限を長くしても良い
- リフレッシュトークンを使用して、ユーザのログイン操作なしでトークンの再発行が可能
- ステートフル認証はサーバ負荷が高いとしたが、相対的な評価
- スケーラビリティが重視されない限り、ステートフル形式の方が良さそう？
- どちらを選択するかは、セキュリティ要件次第
- 例. パスワード変更時、認証の即時失効が必須かどうか
- フィッシングでパスワードが流出した場合等が該当
- 例. パスワード変更時、認証の即時失効が必須かどうか
- 脅威分析を行ったうえで、リスクを許容するかを検討することが大切
参照
ステートレス認証の実装例
- Static Web AppsはSPA用静的ファイルを提供するWebサーバとして機能
- Auth0が発行するトークンはローカルPCで稼働するWebブラウザで管理
- バックエンドAPIには、アクセストークンを用いてWebブラウザから直接アクセス
ステートフル認証の実装例
- App ServiceにExpressサーバをデプロイ。Expressサーバの機能は下記の通り
- SPA用静的ファイルを提供するWebサーバ
-
Authroization Code Flow with PKCEの
Appの役割 - トークンをセッションに格納し、Redisで管理
- WebブラウザからのAPIエンドポイントリクエストをバックエンドに中継
- IDトークンの検証やSPAの画面遷移時の認証制御
- バックエンドの実装はステートレス認証と共通
おわりに
- Auth0 SDKを使用し、Azure上で稼働するWebアプリの認証制御を行う方法を調査
- ステートレス・ステートフル認証にはそれぞれ長所短所があり、要件に応じてどちらを使うか判断すべき
- 例1. パスワード変更時、認証の即時失効が必要要件 => ステートフル認証
- 例2. スケーラビリティを重視 => ステートレス認証