> ## 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) + "*****MASKED*****";
          }
          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](/docs/ja-jp/authenticate/protocols/oauth) を使用して、アプリケーション内の Auth0 連携を管理している開発者や IT 管理者の方を対象としています。<Tooltip tip="Security Assertion Markup Language (SAML): パスワードなしで 2 者間の認証情報の交換を可能にする標準化されたプロトコル。" cta="用語集を見る" href="/docs/ja-jp/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="/docs/ja-jp/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. [Auth0 Dashboard > Applications > Applications](https://manage.auth0.com/#/applications) に移動し、対象のアプリケーションを選択します。
2. **Advanced Settings** までスクロールし、**OAuth** タブを開きます。
3. **OIDC Conformant** トグルスイッチを有効にして、**Save Changes** をクリックします。

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

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

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

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

<div id="differences">
  ## 違い
</div>

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

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

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

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

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

詳しくは、[OIDC-Conformant Adoptions: Access Tokens](/docs/ja-jp/authenticate/login/oidc-conformant-authentication/oidc-adoption-access-tokens) をご覧ください。

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

* [認可コードフロー](/docs/ja-jp/authenticate/login/oidc-conformant-authentication/oidc-adoption-auth-code-flow): 認証リクエスト、認証レスポンス、コード交換リクエスト、コード交換レスポンス、IDトークンの構造、およびアクセストークンの構造に違いがあります。
* [クライアントクレデンシャルフロー](/docs/ja-jp/authenticate/login/oidc-conformant-authentication/oidc-adoption-client-credentials-flow): 新しいフローが有効になり、アプリケーションはユーザーの代理ではなく自分自身として認証し、API へのアクセスをプログラムから安全に取得できるようになります。
* [暗黙フロー](/docs/ja-jp/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 パラメーターなしで送信された認証リクエストは拒否されます。詳細については、[Mitigate Replay Attacks When Using Implicit Flow](/docs/ja-jp/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post/mitigate-replay-attacks-when-using-the-implicit-flow) を参照してください。
  * 認証で暗黙フローを使用した場合、リフレッシュトークンは返されなくなります。
* [リソース所有者パスワードフロー](/docs/ja-jp/authenticate/login/oidc-conformant-authentication/oidc-adoption-rop-flow): 認証リクエスト、認証レスポンス、IDトークンの構造、およびアクセストークンの構造に違いがあります。具体的には、次のとおりです。

  * 従来の [resource owner endpoint](https://auth0.com/docs/api/authentication#database-ad-ldap-active-) は無効化されており、その結果、このエンドポイントからの埋め込みログイン向けパスワードレス認証も利用できなくなります。[埋め込みログインで Passwordless を実装する](/docs/ja-jp/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](/docs/ja-jp/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="/docs/ja-jp/glossary?term=Refresh+tokens">リフレッシュトークン</Tooltip> は、認証で 暗黙的フロー を使用している場合は返されなくなります。
* リフレッシュトークンは機密アプリケーションで使用できますが、<Tooltip tip="リフレッシュトークンローテーション: 脆弱性を最小限に抑えるために、リフレッシュトークンを頻繁に置き換える戦略です。リフレッシュトークンローテーションでは、アプリケーションがリフレッシュトークンを新しいアクセストークンと交換するたびに、Auth0 は新しいリフレッシュトークンも返します。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=refresh+token+rotation">リフレッシュトークンローテーション</Tooltip> を使うことで、ほとんどのフローでセキュリティを強化できます。また、PKCE を使用する 認可コードフロー では、公開アプリケーションでは常にこれを使用する必要があります。機密アプリケーションについては、[Confidential and Public Applications](/docs/ja-jp/get-started/applications/confidential-and-public-applications) を参照してください。リフレッシュトークンローテーションの詳細については、[Refresh Token Rotation](/docs/ja-jp/secure/tokens/refresh-tokens/refresh-token-rotation) を参照してください。
* 新しいトークンを取得する際は、`/oauth/token` エンドポイントを使用してください。
* 認証リクエストで `offline_access` スコープを使用してリフレッシュトークンをリクエストする場合、`device` パラメーターは不要になりました。

詳しくは、[OIDC-Conformation Adoption: Refresh Tokens](/docs/ja-jp/authenticate/login/oidc-conformant-authentication/oidc-adoption-refresh-tokens) を参照してください。

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

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

詳しくは、[OIDC 準拠への移行: シングルサインオン](/docs/ja-jp/authenticate/login/oidc-conformant-authentication/oidc-adoption-sso) を参照してください。

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

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