認証
ユーザー管理
カスタマイズ
Auth0 AI
プラットフォーム- 秘密として安全に扱う: 署名鍵は他の認証情報と同様に扱い、必要なサービスにのみ開示してください。
- ペイロードに機密データを追加しない: トークンは改ざんを防ぐために署名されていますが、簡単にデコードできます。パフォーマンスとセキュリティの両面から、ペイロードに含める クレーム は必要最小限にしてください。
- トークンに有効期限を設定する: 技術的には、トークンはいったん署名されると、署名鍵が変更されるか有効期限が明示的に設定されない限り、無期限に有効です。これは問題の原因になり得るため、トークンを期限切れにする、または失効させるための戦略を用意してください。
- HTTPS を使用する: HTTPS 以外の接続でトークンを送信しないでください。そのようなリクエストは傍受され、トークンが侵害されるおそれがあります。
- 認可のユースケースを網羅的に検討する: 要件を満たすには、トークンが自分のサーバーで生成されたことを保証するための追加のトークン検証システムが必要になる場合があります。
- 保存して再利用する: 不要な往復通信を減らしてアプリケーションの攻撃対象領域を広げないようにし、をから取得して保存することで、プランのトークン数の上限を最適化できます (該当する場合) 。新しいトークンを要求する代わりに、保存したトークンが期限切れになるまでは、以後の呼び出しでそのトークンを使用してください。トークンの保存方法は、アプリケーションの特性によって異なります。一般的な方法としては、データベース (セッションの有無にかかわらず API 呼び出しを実行する必要があるアプリ向け) や HTTP セッション (アクティビティの時間枠がインタラクティブなセッションに限定されるアプリ向け) があります。サーバー側での保存とトークン再利用の例については、トークンの保存を参照してください。
Authorization ヘッダーにそのトークンを設定することで実装されます。トークンには、 のような標準形式を使用するのが望ましいです。ほとんどのプラットフォームには対応ライブラリがあり、独自に暗号処理を実装する必要がないためです。
どちらの方法でも、ユーザーから取得できる情報量は同じです。これは、ログインリクエストで送信される scope パラメーター (Lock、当社の JavaScript ライブラリ、または通常のリンクを使用する場合) によって制御されます。scope は .signin({scope: 'openid name email'}) メソッドのパラメーターで、最終的にはログインリクエストのクエリ文字列の一部になります。
デフォルトでは、トークンベースの認証でトークンが大きくなりすぎるのを避けるため、scope=openid を使用します。トークンに含めたい標準の Connect (OIDC) クレームは、それらをスコープ値として追加することで制御できます。たとえば、scope=openid name email family_name address phone_number のようになります。詳しくは、openid.net の Standard Claims を参照してください。
トークンベースの認証とクッキーベースの認証は組み合わせて使用できます。Web アプリと API が同じドメインから提供されている場合は、クッキーで問題なく動作するため、トークンベースの認証が不要なこともある点に注意してください。必要であれば、Web アプリのフローでも JWT を返します。実装方法は SDK ごとに異なります。JavaScript から API を呼び出す場合 (既存のクッキーを使用する代わりに) は、トークンの送信と保存を処理するために、Web Worker または JavaScript クロージャを使ってアクセストークンを設定する必要があります。詳しくは、トークンの保存 ページの Browser in-memory scenarios セクションを参照してください。
リフレッシュトークンの使用
- Authorization Code Flow
- Proof Key for Code Exchange (PKCE) を使用する Authorization Code Flow
- Resource Owner Password Flow
- デバイス認可フロー
offline_access スコープを含めていても、Auth0 はその API に対するリフレッシュトークンを返しません。
Rules はリフレッシュトークン交換時にも実行されます。特別なロジックを実行するには、Rule の context.protocol プロパティを確認します。値が oauth2-refresh-token であれば、その Rule は交換中に実行されています。
リフレッシュトークンを取得しようとする場合、 パラメーターは Rules の context オブジェクトでは使用できません。対象者 パラメーターを追加しようとしてエラーが発生する場合は、トークンにその値を設定していないことを確認してください。
context.redirect でリダイレクトしようとすると、認証フローはエラーを返します。
Rule を使用してトークンにカスタムクレームを追加している場合、その Rule が存在する限り、リフレッシュトークンの使用時に発行される新しいトークンにもカスタムクレームが含まれます。新しいトークンが自動的にカスタムクレームを引き継ぐわけではありませんが、リフレッシュトークンフロー中にも Rules が実行されるため、同じコードが実行されます。これにより、すでに認可されているアプリケーションに新しいリフレッシュトークンの取得を求めることなく、新たに発行されたトークンのカスタムクレームを追加または変更できます。
リフレッシュトークンの上限
自動テスト
- Management API でユーザーを作成します。このユーザーをテストに使用します。
- レスポンスで
user_idが返されるので、後で使用できるようテスト中はこれを保持しておく必要があります。 - テストが完了したら、Management API からユーザーを削除します。テストユーザーを削除すると、リフレッシュトークンを含む関連アーティファクトも削除されます。
- Management API の device credential エンドポイントを使用して、ユーザーのリフレッシュトークンを一覧表示します。このエンドポイントは、蓄積されているトークン数やページネーションの使用有無にかかわらず、特定の順序なしで最大 1000 個のトークンを返します。
- DELETE メソッドを使用してそれらの認証情報を削除します。
- ユーザーが 1,000 個を超えるトークンを持っている場合は、そのユーザーのトークンがなくなるまで、トークンの一覧表示と削除を繰り返します。
有効期限付きリフレッシュトークンを設定する
offline_access を要求すると、ユーザーに新しいリフレッシュトークンが発行されます。ユーザーが同じデバイスでログアウトしたあとに再度ログインした場合も、新しいリフレッシュトークンが発行されます。アプリケーションでリフレッシュトークンを保存および使用する方法によっては、最初のログイン時に発行された古いリフレッシュトークンは不要になる可能性があります。また、両方のトークンが同じ対象者に対して発行されている場合、通常は新しいリフレッシュトークンが使用されます。詳しくは、トークンの保存を参照してください。
不要になったリフレッシュトークンが蓄積するのを防ぐため、リフレッシュトークン数の上限によって最も古いトークンから削除されるとはいえ、リフレッシュトークンの有効期限を設定することをお勧めします。ローテーションされるリフレッシュトークンとローテーションされない (再利用可能な) リフレッシュトークンは、どちらもアイドル有効期限または絶対有効期限のいずれかを使用して期限切れになるよう設定できます。どちらの有効期限も、アクティブに使用されていないトークンを削除し、ユーザーごとのトークンの蓄積を防ぐのに役立ちます。詳しくは、リフレッシュトークンの有効期限を設定するを参照してください。
JWTの検証
署名アルゴリズム
- RS256 (SHA-256 を使用する RSA 署名): 非対称アルゴリズムです。つまり、2 つの鍵があり、1 つは公開鍵、もう 1 つは秘密として保持する必要がある秘密鍵です。Auth0 は署名の生成に使用する秘密鍵を保持し、JWT の利用者は Auth0 が提供するメタデータエンドポイントから公開鍵を取得して、それを使用して JWT 署名を検証 します。
- HS256 (SHA-256 を使用する HMAC): 対称アルゴリズムです。つまり、秘密として保持する必要がある鍵は 1 つだけで、それを 2 者間で共有します。同じ鍵を署名の生成と検証の両方に使用するため、鍵が漏えいしないよう注意が必要です。この秘密鍵 (またはシークレット) は、アプリケーション () または API (Signing Secret) を登録し、HS256 署名アルゴリズムを選択したときに作成されます。
- RS256 では、秘密鍵の保持者 (Auth0) のみがトークンに署名でき、公開鍵を使って誰でもそのトークンが有効かどうかを確認できます。
- RS256 では、複数のオーディエンスに対して有効なトークンをリクエストできます。
- RS256 では、秘密鍵が漏えいした場合でも、新しいシークレットでアプリケーションまたは API を再デプロイしなくても鍵ローテーションを実装できます (HS256 を使用している場合は再デプロイが必要です) 。
- HS256 では、秘密鍵が漏えいした場合、新しいシークレットで API を再デプロイする必要があります。