Skip to main content
Auth0 は、認定済みの OpenID Connect (OIDC) プロバイダーです。Auth0 では、セキュリティと標準ベースの相互運用性を向上させる取り組みの一環として、OIDC 仕様に厳密に準拠した認証フローにのみ新機能を展開しています。 ここでは、OIDC 準拠パイプラインとレガシーパイプラインの違いを説明し、既存のアプリケーションをどのように移行すべきかについての提案を示します。OAuth 2.0 Authorization Framework を使用して、アプリケーション内の Auth0 連携を管理している開発者や IT 管理者の方を対象としています。 または WS-Federation を使用している場合、この情報は該当しません。すべての認証フローは、特定の言語やライブラリ実装の文脈ではなく、HTTP リクエストベースで説明しています。 すべての新機能は OIDC 準拠パイプラインのみを対象としており、従来の Auth0 SDK のすべてのバージョンは非推奨であるため、新機能や重大ではないセキュリティ問題に対する更新は提供されず、最終的には廃止されます。さらに、このガイド以外のすべてのドキュメント、ライブラリ、サンプルは、OIDC 準拠パイプラインにのみ適用されます。そのため、当面は新機能を活用する予定がない場合でも、OIDC 準拠パイプラインを採用することを強くお勧めします。

​
OIDC準拠パイプラインを適用する

テナントの作成時期によって、OIDC準拠パイプラインの適用方法の選択肢が異なる場合があります。

​
新しいテナント

を使って新しいテナントを作成すると、デフォルトで OIDC 準拠パイプラインが使用されます。これは 2019 年初頭から Auth0 Dashboard のデフォルト設定です。
OIDC Conformant 設定を手動で無効にしている可能性もあります。その場合は、古いテナント向けの手順に従ってください。

​
以前のテナント

このガイドで説明している変更を、特定のアプリケーションに対して一括で強制適用し、実行時ではなく設定時にすべての破壊的変更に対処したい場合は、次の操作が必要です。
  1. Auth0 Dashboard > Applications > Applications に移動し、対象のアプリケーションを選択します。
  2. Advanced Settings までスクロールし、OAuth タブを開きます。
  3. OIDC Conformant トグルスイッチを有効にして、Save Changes をクリックします。
認証リクエストごとに OIDC 準拠パイプラインを使用し、かつアプリケーションで を使って API を呼び出す必要がある場合は、audience パラメーターを付けて /social エンドポイントへのリクエストを開始します。 認証リクエストごとに OIDC 準拠パイプラインを使用し、アプリケーションで API を呼び出す必要がない場合は、次の audience パラメーターを使用します。

​
違い

OIDC 準拠のパイプラインを有効にすると、レガシーパイプラインには次のような変更があります。

​
APIs

アプリケーションと API (リソース) は、それぞれ別個の Auth0 エンティティとして定義する必要があります。詳しくは、OIDC-Conformant Adoption: APIs をご覧ください。

​
アクセストークン

  • API は、 ではなく、アクセストークンで保護する必要があります。違いについて詳しくは、Tokens をご覧ください。
  • ユーザーに関する標準クレームの定義済みセットは、IDトークン または /userinfo のレスポンスで返すことができます。
  • カスタムクレームは、名前空間付きの形式に準拠している必要があります。詳しくは、Create Namespaced Custom Claims をご覧ください。
  • /userinfo のレスポンスは、IDトークン の内容と同様に、OIDC 仕様に準拠します
  • スコープを使用して、標準クレームまたはカスタム API 権限のいずれかをリクエストできます。
詳しくは、OIDC-Conformant Adoptions: Access Tokens をご覧ください。

​
認可フロー

  • 認可コードフロー: 認証リクエスト、認証レスポンス、コード交換リクエスト、コード交換レスポンス、IDトークンの構造、およびアクセストークンの構造に違いがあります。
  • クライアントクレデンシャルフロー: 新しいフローが有効になり、アプリケーションはユーザーの代理ではなく自分自身として認証し、API へのアクセスをプログラムから安全に取得できるようになります。
  • 暗黙フロー: 認証リクエスト、認証レスポンス、IDトークンの構造、およびアクセストークンの構造に違いがあります。具体的には、次のとおりです。
    • response_type=token ではアクセストークンのみが返されます。IDトークンを取得するには、response_type=id_token または response_type=token id_token を使用してください。
    • IDトークンは RS256 を使用して非対称署名されます。
    • nonce パラメーターなしで送信された認証リクエストは拒否されます。詳細については、Mitigate Replay Attacks When Using Implicit Flow を参照してください。
    • 認証で暗黙フローを使用した場合、リフレッシュトークンは返されなくなります。
  • リソース所有者パスワードフロー: 認証リクエスト、認証レスポンス、IDトークンの構造、およびアクセストークンの構造に違いがあります。具体的には、次のとおりです。
    • 従来の resource owner endpoint は無効化されており、その結果、このエンドポイントからの埋め込みログイン向けパスワードレス認証も利用できなくなります。埋め込みログインで Passwordless を実装する には、アプリケーションの種類に応じて Embedded Passwordless API または当社の SDK を使用する必要があります。
    • offline_access スコープを使用してリフレッシュトークンをリクエストする場合、device パラメーターは無効と見なされるようになりました。

​
デリゲーション

  • 非推奨: サードパーティ API トークンの取得に使用する場合を除き、/delegation エンドポイントは非推奨です。
  • OIDC 準拠のアプリケーションは、デリゲーションリクエストの送信元にも送信先にもできません。
詳しくは、OIDC-Conformant Adoption: Delegation をご覧ください。

​
エンドポイント

  • 非推奨: /tokeninfo エンドポイント
  • 無効: /oauth/access_token エンドポイント (ネイティブモバイルアプリケーションからのソーシャル認証に使用) 。
  • 非推奨: /ssodata エンドポイント
  • 非推奨: サードパーティ API トークンの取得に使用する場合を除き、/delegation エンドポイント

​
リフレッシュトークン

  • は、認証で 暗黙的フロー を使用している場合は返されなくなります。
  • リフレッシュトークンは機密アプリケーションで使用できますが、 を使うことで、ほとんどのフローでセキュリティを強化できます。また、PKCE を使用する 認可コードフロー では、公開アプリケーションでは常にこれを使用する必要があります。機密アプリケーションについては、Confidential and Public Applications を参照してください。リフレッシュトークンローテーションの詳細については、Refresh Token Rotation を参照してください。
  • 新しいトークンを取得する際は、/oauth/token エンドポイントを使用してください。
  • 認証リクエストで offline_access スコープを使用してリフレッシュトークンをリクエストする場合、device パラメーターは不要になりました。
詳しくは、OIDC-Conformation Adoption: Refresh Tokens を参照してください。

​
シングルサインオン (SSO)

  • は Auth0 のログインページでのみ実行できるため、 を使用する必要があります。
  • ユーザーが SSO でログインしているかどうかを確認するには、サイレント認証を使用する必要があります。詳しくは、サイレント認証を設定する を参照してください。
  • 非推奨: /ssodata エンドポイントおよび Lock/auth0.js の getSSOData() メソッド。
詳しくは、OIDC 準拠への移行: シングルサインオン を参照してください。

​
追加機能