Tools
OIDC (OpenID Connect)
OAuth 2.0 の上に載せた認証プロトコル。id_token (JWT) でユーザ識別を追加する。
要点
OIDC = OpenID Connect。OAuth 2.0 の上に載せた「認証」プロトコル。OAuth が扱わない「誰がログインしたか」を追加する。
OAuth 2.0 との違い
- OAuth 2.0: 認可 (authorization)。「このアプリに何をさせて良いか」を token で表す
- OIDC: 認証 (authentication)。「誰がログインしたか」を
id_tokenで表す
同じ Authorization Code Flow を再利用し、レスポンスに id_token を追加する構造。
id_token の中身
JWT (JSON Web Token) 形式。主なクレーム:
| クレーム | 意味 |
|---|---|
iss | 発行者 (例: https://accounts.google.com) |
sub | ユーザ ID (発行者内で一意) |
aud | 対象クライアント (Client ID) |
exp | 有効期限 (UNIX 時刻) |
iat | 発行時刻 |
nonce | リプレイ攻撃対策 |
クライアントは iss の公開鍵 (JWKS エンドポイントから取得) で署名を検証してユーザを識別する。
主な用途
- ソーシャルログイン: 「Google/GitHub でログイン」ボタン
- CI から Cloud への認証: GitHub Actions → AWS/GCP/Azure に短命トークンで push。長期の access key を CI に置かない (漏れたら詰む)
- Kubernetes:
kubectlの認証 (kube-apiserver が id_token を検証) - 企業 SSO: Okta・Auth0・Keycloak が IdP になり複数の内製アプリが OIDC で認証
GitHub Actions の OIDC (よくある構成)
- Actions ワークフローが GitHub の OIDC provider から id_token を取得
- AWS の IAM Role にその id_token を渡す (STS AssumeRoleWithWebIdentity)
- AWS 側は
iss = token.actions.githubusercontent.comとsub = repo:org/repo:ref:refs/heads/mainを検証 - Role を assume した短命の access key を返す
利点: リポジトリに long-lived AWS key を置かない。SUB claim で「main branch からしか deploy できない」等の絞り込みが書ける。
関連
- OAuth 2.0 (認可のみ)
- SAML (OIDC より古い企業向け SSO プロトコル、XML ベース)
- JWT (id_token のフォーマット)
最終更新: