【セキュリティ】OpenID Connect（OIDC）

はじめに

Google ログイン、LINE ログイン、Apple でサインイン…
現代のモバイルアプリや Web サービスは、
「パスワードをアプリに渡さずに、本人確認＋権限付与を行う」
ことが当たり前になりました。

その中心にあるのが OpenID Connect（OIDC）。

この記事では、OAuth→OIDC の流れを“スルッと理解”できるようにまとめます。
Flutter / Android で使える知識としてもそのまま役に立ちます。

---

1. OpenID Connect（OIDC）とは？

OAuth 2.0 に “認証（ログイン）” の仕組みを追加した公式標準仕様。

OAuth 2.0 は本来、認可（権限を与えるフレームワーク）。
「ログイン用」ではありません。

しかしアプリ開発者が本当に欲しいのは：

• そのユーザーは誰？
• すでにログインしている？
• メールアドレスは？
• 本人確認はどの方法で行われた？

➡ OIDC は、この “認証” の不足を ID Token（JWT） によって綺麗に補います。

---

2. OAuth と OIDC の違い（要点）

項目	OAuth 2.0	OpenID Connect
目的	認可（APIアクセス権）	認証（ログイン）＋認可
トークン	Access Token / Refresh	Access Token ＋ ID Token
“誰か” が分かる？	✗ 分からない	◎ 分かる（sub, email 等）
必須 scope	任意	openid
主な用途	Google Drive 操作、API 呼び出し	Googleログイン、LINEログイン等

ポイントは ID Token があるかどうか。

---

3. OIDC が登場した背景（歴史）

OAuth 2.0 は “本人確認をしない”

OAuth 2.0 は API 権限の付与だけを行う仕様です。

例：
「このアプリが、あなたの Google Drive を読むことを許可しますか？」

でも実際のアプリはもっと現実的で…

• SNSログインがしたい
• パスワードを相手アプリに渡したくない
• ユーザーのプロフィールが知りたい

こうした“ログイン需要”に OAuth だけでは対応できなかった。

---

OIDC が生まれた理由

そこで設計されたのが OpenID Connect（2014）。
OAuth に 認証の層 を追加し、スマートフォン時代に最適化された “ログイン基盤” になった。

IDC・Google・Microsoft・LINE・Amazon など、大手サービスは基本 OIDC ベース。

---

4. OpenID Connect の全体フロー（図解）

実際のログインフローを Mermaid で可視化するとこうなる👇

ここが重要

OIDC は ID Token を介してユーザーが誰かを知る。
OAuth は Access Token だけなので“本人確認”はできない。

---

5. OIDC が返す主要トークン

OIDC の心臓部は ID Token（JWT）。

ID Token とは？

• ユーザーの本人確認情報が入った JWT
• クライアント側が直接検証できる
• ログインセッション判定に使う

Access Token

API を叩くための「権限証書」。

Refresh Token

長期ログインのため（Public Client では PKCE の組み合わせが重要）。

---

6. ID Token に含まれる主な Claims

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "com.example.myapp",
  "exp": 1718256720,
  "iat": 1718253120,
  "email": "[e-mail]",
  "email_verified": true,
  "auth_time": 1718253100,
  "amr": ["pwd", "otp"], 
  "nonce": "abc123"
}

Claim	説明
sub	ユーザーを表す一意識別子（最重要）
iss	発行者
aud	このTokenを受け取ってよいClient
exp	Token有効期限
auth_time	認証した時刻
amr	認証方法（Password / SMS / FaceID 等）
nonce	Replay防止に必須

---

7. 認証方法 amr（Authentication Methods References）

OIDC が OAuth に比べて一段“強い”のはここ。

例：

"amr": ["pwd", "otp"]

= パスワード＋SMS（MFA）。

amr の代表例

値	意味
pwd	パスワード
otp	ワンタイムパス
mfa	多要素認証
face	顔認証
fingerprint	指紋
hwk	ハードウェアキー（FIDO2/YubiKey）

---

8. OIDC の3つの主要 Endpoint

Endpoint	説明
/authorize	認証＋同意画面へリダイレクト
/token	Authorization Code を Access/ID Token に交換
/userinfo	メール/名前などの追加プロフィール

他に /jwks.json（公開鍵セット）も重要。

---

9. PKCE と OIDC の組み合わせ（現代標準）

モバイルアプリや SPA が OIDC を使うなら：

• Authorization Code Flow
• ＋PKCE（code_verifier / code_challenge）
• HTTPS のみ
• SecureStorage 管理

これが 2025 年現在の“絶対に崩せない鉄板構成”。

---

10. なぜ OIDC を使うと安全なのか？

10.1 パスワードをクライアントに渡さない

アプリは Auth Server のログイン画面に飛ばすだけ。

10.2 ID Token による署名検証

クライアントは Auth Server の公開鍵で検証できる。
改ざん不能。

10.3 nonce による Replay攻撃防止

10.4 認証強度（amr）の検証が可能

銀行アプリでは必須。

10.5 Refresh Token Rotation

Token の盗難対策が可能。

---

まとめ

• OIDC = OAuth に“ユーザー認証”を追加した標準
• 必須 scope は openid
• ID Token（JWT）で本人が誰か保証する
• 認証方法は amr で確認できる
  （pwd / otp / face / hwk など）
• Authorization Code Flow（＋PKCE）が必須
• Access Token は API 用、ID Token はログイン用

OIDC を理解すると、OAuth の弱点が一気に補完され、
“モダンなログイン”を自分のアプリに完全装備できる ようになります。