OIDC トークン（OIDC Token）

OpenID Connect（OIDC）は OAuth 2.0 の上に「この人は誰か」を伝える認証レイヤーを載せた仕様だ。OAuth 2.0 単体では「このトークンの持ち主にリソースへのアクセスを許可してよい」という認可しか扱えず、ログインしたユーザーが誰なのかをアプリケーション側で知る標準的な手段がなかった。OIDC はその欠落を 3 種類のトークンで埋める。

### 3 つのトークンの役割 **ID トークン**が OIDC の中核にあたる。JWT（JSON Web Token）形式で発行され、ペイロードにはユーザー識別子（`sub`）、発行元（`iss`）、有効期限（`exp`）などのクレームが含まれる。署名を検証すれば改ざんの有無を即座に判定でき、IdP（Identity Provider）へ問い合わせる必要がない。

この「自己完結した身分証」としての性質が、マイクロサービス間の認証コストを下げる鍵になっている。**アクセストークン**は OAuth 2.0 由来で、API やリソースサーバーへのアクセス権を表す。スコープ（`openid profile email` など）で権限範囲を制限し、有効期限は通常数分〜1 時間程度と短く設定される。

**リフレッシュトークン**はアクセストークンの有効期限が切れた際に、ユーザーに再ログインを求めずに新しいトークン一式を取得するために使う。長期間有効なぶん漏洩リスクが高く、サーバーサイドでのみ保持し、ローテーション（使用ごとに新しいリフレッシュトークンに差し替え）を有効にするのが実務上の定石だ。### フローの概要 典型的な Authorization Code Flow では、ユーザーが IdP でログインすると認可コードがクライアントに返される。

クライアントはこのコードを IdP のトークンエンドポイントに送り、ID トークン・アクセストークン・リフレッシュトークンの 3 点をまとめて受け取る。認可コードは一度しか使えず有効期間も極めて短いため、トークン自体がネットワーク上を流れる回数を最小化できる。### 実装上の注意点 筆者が見落としがちだと感じるのはトークンの保管場所だ。

SPA（Single Page Application）ではブラウザの `localStorage` にアクセストークンを保存するパターンが紹介されることがあるが、XSS 攻撃で容易に窃取される。BFF（Backend for Frontend）パターンで HttpOnly Cookie に格納するか、サーバーサイドのセッションストアに保持するほうが安全性は高い。トークンの有効期限設計にも注意が要る。

ID トークンの `exp` が長すぎると、ユーザーの権限変更やアカウント停止が即座に反映されない。短くしすぎるとリフレッシュ頻度が上がり IdP への負荷が増す。多くの IdP は ID トークン 5〜15 分、アクセストークン 1 時間、リフレッシュトークン 30〜90 日をデフォルトとしており、まずはこの範囲から調整するのが現実的だ。