メインコンテンツへスキップ
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. Dashboard > Applications > Applications に移動し、対象のアプリケーションを選択します。
  2. Advanced Settings までスクロールし、OAuth タブを開きます。
  3. OIDC Conformant トグルスイッチを有効にして、Save Changes をクリックします。
認証リクエストごとに OIDC 準拠パイプラインを使用し、かつアプリケーションが を使用して API を呼び出す必要がある場合は、/social エンドポイントへのリクエストを audience パラメーター付きで開始します。 認証リクエストごとに OIDC 準拠パイプラインを使用し、アプリケーションが API を呼び出す必要がない場合は、次の audience パラメーターを使用します。

​
相違点

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

​
API

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

​
アクセストークン

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

​
認可フロー

  • Authorization Code Flow: 認証リクエスト、認証レスポンス、認可コード交換リクエスト、認可コード交換レスポンス、IDトークンの構造、およびアクセストークンの構造に違いがあります。
  • Client Credentials Flow: 新しいフローが有効になり、アプリケーションは (ユーザーの代理ではなく) アプリケーション自体として認証して、プログラムから安全に API へのアクセス権を取得できるようになりました。
  • Implicit Flow: 認証リクエスト、認証レスポンス、IDトークンの構造、およびアクセストークンの構造に違いがあります。具体的には次のとおりです。
    • response_type=token はアクセストークンのみを返します。IDトークンを取得するには、response_type=id_token または response_type=token id_token を使用してください。
    • IDトークンは RS256 を使用して非対称署名されます。
    • nonce パラメーターを指定しない認証リクエストは拒否されます。詳しくは、Implicit Flow 使用時のリプレイ攻撃を軽減する を参照してください。
    • 認証に Implicit Flow を使用した場合、リフレッシュトークンは返されなくなります。
  • Resource Owner Password Flow: 認証リクエスト、認証レスポンス、IDトークンの構造、およびアクセストークンの構造に違いがあります。具体的には次のとおりです。
    • 従来の resource owner endpoint は無効化されているため、そのエンドポイントを使用した埋め込みログインでのパスワードレス認証も利用できなくなります。埋め込みログインでパスワードレスを実装する には、アプリケーションの種類に応じて Embedded Passwordless API または当社の SDK を使用する必要があります。
    • offline_access スコープを使用してリフレッシュトークンを要求する場合、device パラメーターは無効と見なされるようになりました。

​
委任

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

​
エンドポイント

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

​
リフレッシュトークン

  • は、認証に Implicit Flow を使用した場合には返されなくなります。
  • リフレッシュトークンは機密アプリケーションで使用できますが、 によって、多くのフローでセキュリティを強化できます。また、Authorization Code Flow with PKCE を使用する公開アプリケーションでは、必ず使用する必要があります。機密アプリケーションについては、Confidential and Public Applications を参照してください。リフレッシュトークンローテーションの詳細については、Refresh Token Rotation を参照してください。
  • 新しいトークンを取得するには、/oauth/token エンドポイントを使用する必要があります。
  • 認証リクエストで offline_access スコープを使用してリフレッシュトークンをリクエストする場合、device パラメーターは不要になりました。
詳細については、OIDC 準拠への移行: リフレッシュトークン を参照してください。

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

  • は Auth0 のログインページでのみ利用できるため、 を使用する必要があります。
  • ユーザーが SSO でログインしているかどうかを確認するには、サイレント認証を使用する必要があります。詳しくは、Configure Silent Authentication を参照してください。
  • 非推奨: Lock/auth0.js の /ssodata エンドポイントおよび getSSOData() メソッド。
詳しくは、OIDC-Conformant Adoption: Single Sign-On を参照してください。

​
追加機能