> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> OIDC準拠のアプリケーション設定が認証パイプラインに及ぼす影響について説明します。

# OIDC準拠の認証を採用する

export const AuthCodeBlock = ({filename, icon, language, highlight, children}) => {
  const [displayText, setDisplayText] = useState(children);
  const [copyText, setCopyText] = useState(children);
  const wrapperRef = React.useRef(null);
  useEffect(() => {
    let unsubscribe = null;
    function init() {
      if (!window.autorun || !window.rootStore) {
        return;
      }
      unsubscribe = window.autorun(() => {
        let processedChildrenForDisplay = children;
        let processedChildrenForCopy = children;
        for (const [key, value] of window.rootStore.variableStore.values.entries()) {
          const escapedKey = key.replaceAll(/[.*+?^${}()|[\]\\]/g, (String.raw)`\$&`);
          let displayValue = value;
          if (key === "{yourClientSecret}" && value !== "{yourClientSecret}") {
            displayValue = value.substring(0, 3) + "*****マスク済み*****";
          }
          processedChildrenForDisplay = processedChildrenForDisplay.replaceAll(new RegExp(escapedKey, "g"), displayValue);
          processedChildrenForCopy = processedChildrenForCopy.replaceAll(new RegExp(escapedKey, "g"), value);
        }
        setDisplayText(processedChildrenForDisplay);
        setCopyText(processedChildrenForCopy);
      });
    }
    if (window.rootStore) {
      init();
    } else {
      window.addEventListener("adu:storeReady", init);
    }
    return () => {
      window.removeEventListener("adu:storeReady", init);
      unsubscribe?.();
    };
  }, [children]);
  useEffect(() => {
    if (!wrapperRef.current) return;
    const originalWriteText = navigator.clipboard.writeText.bind(navigator.clipboard);
    let isOverriding = false;
    const handleClick = e => {
      const button = e.target.closest('[data-testid="copy-code-button"]');
      if (!button || !wrapperRef.current.contains(button)) return;
      isOverriding = true;
      navigator.clipboard.writeText = text => {
        if (isOverriding) {
          isOverriding = false;
          navigator.clipboard.writeText = originalWriteText;
          return originalWriteText(copyText);
        }
        return originalWriteText(text);
      };
      setTimeout(() => {
        if (isOverriding) {
          isOverriding = false;
          navigator.clipboard.writeText = originalWriteText;
        }
      }, 100);
    };
    const wrapper = wrapperRef.current;
    wrapper.addEventListener('click', handleClick, true);
    return () => {
      wrapper.removeEventListener('click', handleClick, true);
      if (navigator.clipboard.writeText !== originalWriteText) {
        navigator.clipboard.writeText = originalWriteText;
      }
    };
  }, [copyText]);
  return <div ref={wrapperRef}>
      <CodeBlock filename={filename} icon={icon} language={language} lines highlight={highlight}>
        {displayText}
      </CodeBlock>
    </div>;
};

Auth0 は、[認定済みの OpenID Connect (OIDC) プロバイダー](http://openid.net/certification/)です。セキュリティと標準ベースの相互運用性を向上させるための Auth0 の取り組みの一環として、新機能は [OIDC 仕様](http://openid.net/specs/openid-connect-core-1_0.html) に厳密に準拠した認証フローにのみ提供されます。

ここでは、OIDC 準拠パイプラインとレガシーパイプラインの違いを説明し、既存のアプリケーションをどのように適応させるかについての推奨事項を示します。対象となるのは、[OAuth 2.0 Authorization Framework](/ja/docs/authenticate/protocols/oauth) を使用して、アプリケーション内の Auth0 統合を管理している開発者または IT 管理者です。<Tooltip tip="Security Assertion Markup Language (SAML): パスワードなしで 2 者間の認証情報の交換を可能にする標準化されたプロトコル。" cta="用語集を表示" href="/ja/docs/glossary?term=SAML">SAML</Tooltip> または WS-Federation を使用している場合、この情報は該当しません。すべての認証フローは、特定の言語やライブラリ実装の文脈ではなく、HTTP リクエストベースで説明します。

すべての新機能は OIDC 準拠パイプラインのみを対象としており、すべてのレガシー Auth0 SDK バージョンは非推奨で、新機能や重大ではないセキュリティ問題に対する更新は提供されず、最終的には廃止されます。さらに、このガイド以外のすべてのドキュメント、ライブラリ、サンプルは、OIDC 準拠パイプラインにのみ適用されます。そのため、当面は新機能を活用する予定がない場合でも、OIDC 準拠パイプラインを採用することを強く推奨します。

<div id="apply-the-oidc-conformant-pipeline">
  ## OIDC 準拠パイプラインを適用する
</div>

テナントの作成時期によっては、OIDC 準拠パイプラインの適用に使用できるオプションが異なる場合があります。

<div id="new-tenants">
  ### 新しいテナント
</div>

<Tooltip tip="Auth0 Dashboard: サービスを設定するための Auth0 のメイン製品。" cta="用語集を表示" href="/ja/docs/glossary?term=Auth0+Dashboard">Auth0 Dashboard</Tooltip> を使用して新しいテナントを作成した場合、OIDC 準拠パイプラインがデフォルトで使用されます。これは、2019 年初頭以降、Auth0 Dashboard のデフォルト設定です。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  ただし、OIDC Conformant 設定を手動で無効にしている場合もあります。その場合は、古いテナント向けの手順に従ってください。
</Callout>

<div id="older-tenants">
  ### 古いテナント
</div>

このガイドで説明している変更を、特定のアプリケーションに対して一度にすべて強制適用し、実行時ではなく設定時にすべての破壊的変更を把握したい場合は、次の操作が必要です。

1. [Dashboard > Applications > Applications](https://manage.auth0.com/#/applications) に移動し、対象のアプリケーションを選択します。
2. **Advanced Settings** までスクロールし、**OAuth** タブを開きます。
3. **OIDC Conformant** トグルスイッチを有効にして、**Save Changes** をクリックします。

認証リクエストごとに OIDC 準拠パイプラインを使用し、かつアプリケーションが <Tooltip tip="アクセストークン: API へのアクセスに使用される、不透明な文字列または JWT 形式の認可資格情報。" cta="用語集を表示" href="/ja/docs/glossary?term=JWT">JWT</Tooltip> <Tooltip tip="JSON Web Token (JWT): 2 者間でクレームを安全に表現するために使用される標準的な IDトークン形式（および多くの場合はアクセストークン形式）。" cta="用語集を表示" href="/ja/docs/glossary?term=access+token">アクセストークン</Tooltip> を使用して API を呼び出す必要がある場合は、[`/social`](https://auth0.com/docs/api/authentication#social) エンドポイントへのリクエストを `audience` パラメーター付きで開始します。

認証リクエストごとに OIDC 準拠パイプラインを使用し、アプリケーションが API を呼び出す必要がない場合は、次の `audience` パラメーターを使用します。

export const codeExample = `https://{yourDomain}/userinfo`;

<AuthCodeBlock children={codeExample} language="http" />

<div id="differences">
  ## 相違点
</div>

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

<div id="apis">
  ### API
</div>

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

<div id="access-tokens">
  ### アクセストークン
</div>

* API の保護には、<Tooltip tip="IDトークン: リソースへのアクセスではなく、クライアント自体のための認証情報です。" cta="用語集を見る" href="/ja/docs/glossary?term=ID+tokens">IDトークン</Tooltip> ではなくアクセストークンを使用する必要があります。違いの詳細については、[Tokens](/ja/docs/secure/tokens) を参照してください。
* ユーザーに関する定義済みの標準クレームのセットは、IDトークンまたは `/userinfo` のレスポンスで返される場合があります。
* カスタムクレームは、所定の名前付き形式に準拠している必要があります。詳細については、[Create Namespaced Custom Claims](/ja/docs/secure/tokens/json-web-tokens/create-custom-claims) を参照してください。
* `/userinfo` のレスポンスは、IDトークンの内容と同様に、OIDC 仕様に準拠します。
* スコープを使用して、標準クレームまたはカスタム API 権限を要求できます。

詳細については、[OIDC-Conformant Adoptions: Access Tokens](/ja/docs/authenticate/login/oidc-conformant-authentication/oidc-adoption-access-tokens) を参照してください。

<div id="authorization-flows">
  ### 認可フロー
</div>

* [Authorization Code Flow](/ja/docs/authenticate/login/oidc-conformant-authentication/oidc-adoption-auth-code-flow): 認証リクエスト、認証レスポンス、認可コード交換リクエスト、認可コード交換レスポンス、IDトークンの構造、およびアクセストークンの構造に違いがあります。
* [Client Credentials Flow](/ja/docs/authenticate/login/oidc-conformant-authentication/oidc-adoption-client-credentials-flow): 新しいフローが有効になり、アプリケーションは (ユーザーの代理ではなく) アプリケーション自体として認証して、プログラムから安全に API へのアクセス権を取得できるようになりました。
* [Implicit Flow](/ja/docs/authenticate/login/oidc-conformant-authentication/oidc-adoption-implicit-flow): 認証リクエスト、認証レスポンス、IDトークンの構造、およびアクセストークンの構造に違いがあります。具体的には次のとおりです。

  * `response_type=token` はアクセストークンのみを返します。IDトークンを取得するには、`response_type=id_token` または `response_type=token id_token` を使用してください。
  * IDトークンは RS256 を使用して非対称署名されます。
  * nonce パラメーターを指定しない認証リクエストは拒否されます。詳しくは、[Implicit Flow 使用時のリプレイ攻撃を軽減する](/ja/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post/mitigate-replay-attacks-when-using-the-implicit-flow) を参照してください。
  * 認証に Implicit Flow を使用した場合、リフレッシュトークンは返されなくなります。
* [Resource Owner Password Flow](/ja/docs/authenticate/login/oidc-conformant-authentication/oidc-adoption-rop-flow): 認証リクエスト、認証レスポンス、IDトークンの構造、およびアクセストークンの構造に違いがあります。具体的には次のとおりです。

  * 従来の [resource owner endpoint](https://auth0.com/docs/api/authentication#database-ad-ldap-active-) は無効化されているため、そのエンドポイントを使用した埋め込みログインでのパスワードレス認証も利用できなくなります。[埋め込みログインでパスワードレスを実装する](/ja/docs/authenticate/login/universal-vs-embedded-login) には、アプリケーションの種類に応じて Embedded Passwordless API または当社の SDK を使用する必要があります。
  * `offline_access` スコープを使用してリフレッシュトークンを要求する場合、`device` パラメーターは無効と見なされるようになりました。

<div id="delegation">
  ### 委任
</div>

* **非推奨**: サードパーティ API トークンの取得に使用する場合を除き、[`/delegation`](https://auth0.com/docs/api/authentication#delegation) エンドポイントは非推奨です。
* OIDC 準拠アプリケーションは、委任リクエストの送信元にも送信先にもできません。

詳しくは、[OIDC-Conformant Adoption: Delegation](/ja/docs/authenticate/login/oidc-conformant-authentication/oidc-adoption-delegation) を参照してください。

<div id="endpoints">
  ### エンドポイント
</div>

* **非推奨**: `/tokeninfo` エンドポイント
* **無効化**: [`/oauth/access_token`](https://auth0.com/docs/api/authentication#post-oauth-access_token) エンドポイント (ネイティブモバイルアプリからのソーシャル認証に使用)
* **非推奨**: `/ssodata` エンドポイント
* **非推奨**: サードパーティ製 API のトークン取得に使用する場合を除く [`/delegation`](https://auth0.com/docs/api/authentication#delegation) エンドポイント

<div id="refresh-tokens">
  ### リフレッシュトークン
</div>

* <Tooltip tip="リフレッシュトークン: ユーザーに再度ログインを求めることなく、新しいアクセストークンを取得するために使用されるトークン。" cta="用語集を見る" href="/ja/docs/glossary?term=Refresh+tokens">リフレッシュトークン</Tooltip> は、認証に Implicit Flow を使用した場合には返されなくなります。
* リフレッシュトークンは機密アプリケーションで使用できますが、<Tooltip tip="リフレッシュトークンローテーション: 脆弱性を最小限に抑えるために、リフレッシュトークンを頻繁に置き換える戦略。リフレッシュトークンローテーションでは、アプリケーションがリフレッシュトークンを新しいアクセストークンと交換するたびに、Auth0 は新しいリフレッシュトークンも返します。" cta="用語集を見る" href="/ja/docs/glossary?term=refresh+token+rotation">リフレッシュトークンローテーション</Tooltip> によって、多くのフローでセキュリティを強化できます。また、Authorization Code Flow with PKCE を使用する公開アプリケーションでは、必ず使用する必要があります。機密アプリケーションについては、[Confidential and Public Applications](/ja/docs/get-started/applications/confidential-and-public-applications) を参照してください。リフレッシュトークンローテーションの詳細については、[Refresh Token Rotation](/ja/docs/secure/tokens/refresh-tokens/refresh-token-rotation) を参照してください。
* 新しいトークンを取得するには、`/oauth/token` エンドポイントを使用する必要があります。
* 認証リクエストで `offline_access` スコープを使用してリフレッシュトークンをリクエストする場合、`device` パラメーターは不要になりました。

詳細については、[OIDC 準拠への移行: リフレッシュトークン](/ja/docs/authenticate/login/oidc-conformant-authentication/oidc-adoption-refresh-tokens) を参照してください。

<div id="single-sign-on-sso">
  ### シングルサインオン (SSO)
</div>

* <Tooltip tip="シングルサインオン（SSO）: ユーザーが 1 つのアプリケーションにログインすると、他のアプリケーションにも自動的にログインできるようにするサービスです。" cta="用語集を表示" href="/ja/docs/glossary?term=SSO">SSO</Tooltip> は Auth0 のログインページでのみ利用できるため、<Tooltip tip="Universal Login: アプリケーションは、ユーザーの本人確認を行うために、Auth0 の認可サーバーでホストされる Universal Login にリダイレクトします。" cta="用語集を表示" href="/ja/docs/glossary?term=Universal+Login">Universal Login</Tooltip> を使用する必要があります。
* ユーザーが SSO でログインしているかどうかを確認するには、サイレント認証を使用する必要があります。詳しくは、[Configure Silent Authentication](/ja/docs/authenticate/login/configure-silent-authentication) を参照してください。
* **非推奨**: `Lock/auth0.js` の `/ssodata` エンドポイントおよび `getSSOData()` メソッド。

詳しくは、[OIDC-Conformant Adoption: Single Sign-On](/ja/docs/authenticate/login/oidc-conformant-authentication/oidc-adoption-sso) を参照してください。

<div id="additional-features">
  ### 追加機能
</div>

* API向けのサードパーティアプリケーションを作成し、認可時に同意ダイアログを表示できます。詳細は、[ユーザー同意とサードパーティアプリケーション](/ja/docs/get-started/applications/third-party-applications/user-consent-and-third-party-applications)を参照してください。
* 認証時にアプリケーションに提供されるユーザープロファイル情報を制限できます。詳細は、[ユーザープロファイル](/ja/docs/manage-users/user-accounts/user-profiles/user-profile-structure)を参照してください。
* アプリケーションを動的に登録できます。詳細は、[動的クライアント登録](/ja/docs/get-started/applications/dynamic-client-registration)を参照してください。
* [組織](/ja/docs/manage-users/organizations)とその関連機能を利用できるようになります。