メインコンテンツへスキップ
IDに関連したトークンには、IDトークンとアクセストークンの2種類があります。

​
IDトークン

IDトークンは、アプリケーションでのみ使用されるJSON Web Token（JWT）です。たとえば、ユーザーのログインにGoogleを使用して、カレンダーを同期させるアプリの場合、Googleはユーザーに関する情報を含むIDトークンをアプリに送信します。その後、このアプリはトークンの内容を解析し、その情報（名前やプロファイル画像などの詳細を含む）を使ってユーザーエクスペリエンスをカスタマイズします。
IDトークンに含まれる情報を使用する前に、必ずIDトークンを検証してください。この作業にはライブラリーが便利です。
IDトークンを使ってAPIにアクセスしてはいけません 。各トークンには、意図されたオーディエンス（通常は受信者）についての情報が含まれています。 Connectの仕様によると、IDトークンのオーディエンス（aud クレームで示される）は、認証を要求しているアプリケーションのクライアントIDでなければなりません。そうでない場合は、そのトークンを信頼してはいけません。 デコードされたIDトークンの内容は、以下のようになります。 
{
  "iss": "http://{yourDomain}/",
  "sub": "auth0|123456",
  "aud": "{yourClientId}",
  "exp": 1311281970,
  "iat": 1311280970,
  "name": "Jane Doe",
  "given_name": "Jane",
  "family_name": "Doe",
  "gender": "female",
  "birthdate": "0000-10-31",
  "email": "janedoe@example.com",
  "picture": "http://example.com/janedoe/me.jpg"
}
このトークンはアプリケーションに対してユーザーを認証します。トークンのオーディエンス（ aud クレーム）はアプリケーションの識別子に設定されています。つまり、この特定のアプリケーションのみが、このトークンを使用すべきであることを意味します。 逆に言うと、APIはaud 値がAPIの一意の識別子と一致するトークンを予期しています。したがって、アプリケーションとAPIの両方を管理しない限り、IDトークンをAPIに送信しても通常はうまく行きません。IDトークンはAPIによって署名されていないため、APIがIDトークンを受け入れる場合、アプリケーションがトークンを変更したか（例：スコープを追加）を判断する方法がありません。詳しくは、『JWTハンドブック』を参照してください。

​
アクセストークン

アクセストークン（常にとは限らない）は、APIへのアクセスと（付与されたスコープ で指定された）所定のアクションの実行が、トークンの持参人に認可されていることをAPIに知らせるために使用されます。 上記のGoogleの例では、ユーザーがログインし、アプリによるGoogleカレンダーでの読み書きに同意すると、Googleがアプリにアクセストークンを送信します。アプリがGoogleカレンダーに書き込む場合は、HTTP認可 ヘッダーにアクセストークンを含めて、Google Calendar APIに要求を送信します。 アクセストークンは、絶対に 認証に使用してはいけません。アクセストークンはユーザーが認証済みかを判断できません。アクセストークンが持っているユーザー情報は、sub クレームに含まれるユーザーIDだけです。アクセストークンはAPIのためのものであり、アプリケーションはアクセストークンを不透明な文字列として扱わなければなりません。アプリケーションはこれらをデコードしようとしたり、トークンを特定の形式で受け取ることを予期したりできません。 以下はアクセストークンの例です。 
{
  "iss": "https://{yourDomain}/",
  "sub": "auth0|123456",
  "aud": [
    "my-api-identifier",
    "https://{yourDomain}/userinfo"
  ],
  "azp": "{yourClientId}",
  "exp": 1489179954,
  "iat": 1489143954,
  "scope": "openid profile email address phone read:appointments"
}
ID（sub クレーム）を除いて、ユーザーに関する情報がトークンに含まれていないことに注意してください。トークンには、アプリケーションがAPIで実行できるアクションについての認可情報（スコープ クレーム）のみが含まれています。この点で、アクセストークンはAPIのセキュリティ保護に役立ちますが、ユーザーの認証には適していません。 場合によっては、アクセストークンにsubクレーム以外のユーザー情報を追加したり、カスタムクレームを含めたりする方が、ユーザーの詳細取得にAPIの余分な処理を省くため、望ましいこともあります。これを行う場合には、これら追加のクレームがアクセストークンで読み取り可能なことに留意してください。詳細については、「カスタムクレームを作成する」をお読みください。

​
特殊なトークン

Auth0のトークンベースの認証シナリオでは、以下の3つの特殊なトークンが使用されています。
  • リフレッシュトークン ：ユーザーを再認証することなく、更新されたアクセストークンを取得するために使用されます。
  • アクセストークン ：ユーザーの認証後にIDプロバイダーが発行するアクセストークンで、サードパーティのAPIを呼び出すことができます。
  • Auth0 のアクセストークン ：特定のクレーム（スコープ）を含む、短期間だけ有効なトークンで、Management APIエンドポイントを呼び出すことができます。

​
もっと詳しく

⌘I