トークン

IDに関連したトークンには、IDトークンとアクセストークンの2種類があります。

IDトークンは、アプリケーションでのみ使用されるJSON Web Token（JWT）です。たとえば、ユーザーのログインにGoogleを使用して、カレンダーを同期させるアプリの場合、Googleはユーザーに関する情報を含むIDトークンをアプリに送信します。その後、このアプリはトークンの内容を解析し、その情報（名前やプロファイル画像などの詳細を含む）を使ってユーザーエクスペリエンスをカスタマイズします。

IDトークンを使ってAPIにアクセスしてはいけません。各トークンには、意図されたオーディエンス（通常は受信者）についての情報が含まれています。OpenID 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ハンドブック』を参照してください。

アクセストークン（常に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つの特殊なトークンが使用されています。

• リフレッシュトークン：ユーザーを再認証することなく、更新されたアクセストークンを取得するために使用されます。

• IDPアクセストークン：ユーザーの認証後にIDプロバイダーが発行するアクセストークンで、サードパーティのAPIを呼び出すことができます。

• Auth0 Management APIのアクセストークン：特定のクレーム（スコープ）を含む、短期間だけ有効なトークンで、Management APIエンドポイントを呼び出すことができます。

• JSON Webトークン
• IDトークン
• アクセストークン
• リフレッシュトークン
• トークンストレージ
• トークンのベストプラクティス