メインコンテンツへスキップ IDに関連したトークンには、IDトークンとアクセストークンの2種類があります。
IDトークン IDトークン は、アプリケーションでのみ使用されるJSON Web Token（JWT） です。たとえば、ユーザーのログインにGoogleを使用して、カレンダーを同期させるアプリの場合、Googleはユーザーに関する情報を含むIDトークンをアプリに送信します。その後、このアプリはトークンの内容 を解析し、その情報（名前やプロファイル画像などの詳細を含む）を使ってユーザーエクスペリエンスをカスタマイズします。IDトークンを使ってAPIにアクセスしてはいけません 。各トークンには、意図されたオーディエンス（通常は受信者）についての情報が含まれています。OpenID aud クレームで示される）は、認証を要求しているアプリケーションのクライアントIDでなければなりません。そうでない場合は、そのトークンを信頼してはいけません。
デコードされたIDトークンの内容は、以下のようになります。
このトークンはアプリケーションに対してユーザーを認証します。トークンのオーディエンス（ aud クレーム）はアプリケーションの識別子に設定されています。つまり、この特定のアプリケーションのみが、このトークンを使用すべきであることを意味します。
逆に言うと、APIはaud 値がAPIの一意の識別子と一致するトークンを予期しています。したがって、アプリケーションとAPIの両方を管理しない限り、IDトークンをAPIに送信しても通常はうまく行きません。IDトークンはAPIによって署名されていないため、APIがIDトークンを受け入れる場合、アプリケーションがトークンを変更したか（例：スコープを追加）を判断する方法がありません。詳しくは、『JWTハンドブック 』を参照してください。
アクセストークン アクセストークン （常にJWT スコープ で指定された）所定のアクションの実行が、トークンの持参人に認可されていることをAPIに知らせるために使用されます。上記のGoogleの例では、ユーザーがログインし、アプリによるGoogleカレンダーでの読み書きに同意すると、Googleがアプリにアクセストークンを送信します。アプリがGoogleカレンダーに書き込む場合は、HTTP認可 ヘッダーにアクセストークンを含めて、Google Calendar APIに要求を送信します。
アクセストークンは、絶対に 認証 に使用してはいけません。アクセストークンはユーザーが認証済みかを判断できません。アクセストークンが持っているユーザー情報は、sub クレームに含まれるユーザーIDだけです。アクセストークンはAPIのためのものであり、アプリケーションはアクセストークンを不透明な文字列として扱わなければなりません。アプリケーションはこれらをデコードしようとしたり、トークンを特定の形式で受け取ることを予期したりできません。
以下はアクセストークンの例です。
ID（sub クレーム）を除いて、ユーザーに関する情報がトークンに含まれていないことに注意してください。トークンには、アプリケーションがAPIで実行できるアクションについての認可情報（スコープ クレーム）のみが含まれています。この点で、アクセストークンはAPIのセキュリティ保護に役立ちますが、ユーザーの認証には適していません。
場合によっては、アクセストークンにsubクレーム以外のユーザー情報を追加したり、カスタムクレームを含めたりする方が、ユーザーの詳細取得にAPIの余分な処理を省くため、望ましいこともあります。これを行う場合には、これら追加のクレームがアクセストークンで読み取り可能なことに留意してください。詳細については、「カスタムクレームを作成する 」をお読みください。
特殊なトークン Auth0のトークンベースの認証シナリオでは、以下の3つの特殊なトークンが使用されています。
リフレッシュトークン ：ユーザーを再認証することなく、更新されたアクセストークンを取得するために使用されます。IDP Auth0 Management API ：特定のクレーム（スコープ）を含む、短期間だけ有効なトークンで、Management APIエンドポイントを呼び出すことができます。
もっと詳しく 
