OIDC準拠認証の採用
Auth0は認定OpenID Connect (OIDC)プロバイダーです。Auth0 では、セキュリティと標準ベースの相互運用性を向上させる取り組みの一環として、OIDC仕様に厳密に準拠した認証フローにのみ新しい機能を展開しています。
OIDC準拠パイプラインとレガシーパイプラインの違いを説明し、既存のアプリケーションを適応させる方法について説明します。OAuth 2.0認可フレームワークを使用してアプリケーションでAuth0統合を管理する開発者および/またはIT管理者の場合。この情報は、SAMLまたはWSフェデレーションを使用している場合には適用されません。すべての認証フローは、特定の言語またはライブラリ実装のコンテキストではなく、HTTP要求を通じて記述されます。
すべての新機能はOIDC準拠のパイプラインのみを対象としており、すべてのレガシーAuth0 SDKバージョンは非推奨となり、新機能や重大でないセキュリティ問題に対する更新は受信されず、最終的には廃止されます。さらに、本ガイド以外のすべてのドキュメント、ライブラリ、および例は、OIDC準拠のパイプラインにのみ適用されます。このため、近い将来に新しい機能や機能を活用する必要がない場合でも、OIDC準拠のパイプラインを採用することを強くお勧めします。
OIDC準拠のパイプラインの採用
テナントの世代に応じて、OIDC準拠パイプラインを採用するためのさまざまなオプションがある場合があります。
新しいテナント
Auth0ダッシュボードを使用して新しいテナントを作成する場合、デフォルトでOIDC準拠のパイプラインが使用されます。これは、2019年初頭からダッシュボードのデフォルト設定となっています。
OIDC Conformant（OIDC準拠）設定を手動で無効にすることはできますが、以前のテナントに関する指示に従ってください。
古いテナント
本ガイドで説明されているすべての変更を特定のアプリケーションに対して同時に強制し、実行時ではなく構成中にすべての重大な変更を検出できるようにするには、次の操作を行う必要があります。
［Dashboard］>［Applications（アプリケーション）］>［Applications（アプリケーション）］に進み、希望するアプリケーションを選択します。
［Advanced Settings（詳細設定）］にスクロールし、OAuthタブに進みます。
［OIDC Conformant（OIDC準拠）］トグルスイッチを有効にし、［Save Changes（変更を保存）］をクリックします。
認証要求ごとにOIDC準拠のパイプラインを使用する必要があり、アプリケーションがJWTアクセストークンを使用してAPIを呼び出す必要がある場合は、audienceパラメーターを使用して/socialエンドポイントへの要求を開始します。
認証要求ごとにOIDC準拠のパイプラインを使用する必要があり、アプリケーションがAPIを呼び出す必要がない場合は、次のaudienceパラメーターを使用します。
https://{yourDomain}/userinfoWas this helpful?
違い
OIDC準拠パイプラインを有効にすると、従来のパイプラインに次の変更が加えられます。
API
アプリケーションとAPI（リソース）は、個別のAuth0エンティティとして定義してください。詳細は「OIDC準拠の採用：API」をお読みください。
アクセストークン
APIは、IDトークンではなくアクセストークンを使用して保護してください。これらの違いに関する詳細は、「トークン」をお読みください。
ユーザーに関する標準的なクレームの定義済みセットは、IDトークンまたは
/userinfoからの応答で返されます。カスタムクレームは、名前付き形式に準拠する必要があります。詳細については、「名前空間カスタムクレームを作成する」をお読みください。
/userinfoからの応答はIDトークンの内容と同様にOIDC仕様に準拠します。スコープは、標準クレームまたはカスタムAPIアクセス許可のいずれかを要求するために使用できます。
詳細は、「OIDC準拠の採用：アクセストークン」をお読みください。
認可フロー
認可コードフロー：認証要求、認証応答、コード交換要求、コード交換応答、IDトークン構造、アクセストークン構造には構造上の違いがあります。
クライアントの資格情報フロー：新しいフローが有効になり、アプリケーションがユーザーの代わりにではなく自分自身として認証し、プログラムによってセキュアにAPIへのアクセスを取得できるようになりました。
暗黙フロー：認証要求、認証応答、IDトークン構造、アクセストークン構造には構造上の違いがあります。具体的には次のような違いがあります。
response_type=tokenはアクセストークンのみを返します。IDトークンを取得するには、response_type=id_tokenまたはresponse_type=token id_tokenを使用します。IDトークンはRS256を使用して非対称的に署名されます。
nonceパラメーターなしで行われた認証要求は拒否されます。詳細は「暗黙フローの使用時にリプレイ攻撃を軽減する」をお読みください。
認証に暗黙フローを使用すると、リフレッシュトークンは返されなくなります。
リソース所有者のパスワードフロー：認証要求、認証応答、IDトークン構造、アクセストークン構造には構造上の違いがあります。具体的には次のような違いがあります。
従来のリソース所有者エンドポイントが無効になり、そのエンドポイントからの埋め込みログインのパスワードレス認証も無効になります。埋め込みログインでパスワードレスを実装するには、アプリケーションの種類に応じて、埋め込みパスワードレスAPIまたはSDKを使用してください。
offline_accessスコープを使用してリフレッシュトークンを要求する場合、deviceパラメーターは無効と見なされるようになりました。
委任
廃止：
/delegationエンドポイント、サードパーティのAPIトークンを取得するために使用される場合を除く。OIDC準拠のアプリケーションは、委任要求のソースまたはターゲットになることはできません。
詳細は「OIDC準拠の採用：委任」をお読みください。
エンドポイント
廃止：
/tokeninfoエンドポイント無効：
/oauth/access_tokenエンドポイント（ネイティブモバイルアプリケーションからのソーシャル認証に使用）。廃止：
/ssodataエンドポイント廃止：
/delegationエンドポイント、サードパーティーAPIトークンを取得するために使用される場合を除く。
リフレッシュトークン
認証に暗黙フローを使用すると、リフレッシュトークンは返されなくなります。
リフレッシュトークンは機密アプリケーションに使用できますが、リフレッシュトークンのローテーションによりほとんどのフローのセキュリティを強化できるため、PKCEを使用した認証コードフローを使用する場合は、常にパブリックアプリケーションに使用してください。機密アプリケーションの詳細については、「機密アプリケーションと公開アプリケーション」をお読みください。リフレッシュトークンのローテーションの詳細については、「リフレッシュトークンのローテーション」をお読みください。
新しいトークンを取得するときは、
/oauth/tokenエンドポイントを使用してください。認証要求で
offline_accessスコープを使用してリフレッシュトークンを要求する場合、deviceパラメーターは不要になりました。
詳細は「OIDC準拠の採用：リフレッシュトークン」をお読みください。
シングルサインオン（SSO）
SSOはAuth0ログインページからのみ実行できるため、ユニバーサルログインを使用してください。
ユーザーがSSO経由でログインしているかどうかを確認するには、サイレント認証を使用してください。詳細は、「サイレント認証を構成する」をお読みください。
廃止：
/ssodataエンドポイントおよびLock/auth0.jsのgetSSOData()メソッド。
詳細は「OIDC準拠の採用：シングルサインオン」をお読みください。
追加機能
API用のサードパーティーアプリケーションを作成し、認可のための同意ダイアログを表示します。詳細は「ユーザーの同意およびサードパーティーアプリケーション」をお読みください。
認証時にアプリケーションに提供されるユーザープロファイル情報を制限します。詳細は「ユーザープロファイル」をお読みください。
動的にアプリケーションを登録します。詳細については、「動的クライアント登録」をお読みください。
組織とその関連機能が利用可能になります。