OAuthとOIDCの違いが結局分かりにくい...
「OAuthでログインする」
「OIDCはOAuthの拡張」
「access token があればユーザーを識別できるのでは？」
認証・認可まわりを触っていると、このあたりはかなり混ざりやすいです。
自分も最初は、
- OAuth はログインの仕組みなのか
- OIDC は何を追加しているのか
- access token と ID Token はどう使い分けるのか
が頭の中で曖昧でした。
ただ、実装に引きつけて整理すると、本質はそこまで複雑ではありません。
- OAuth 2.0 は認可の仕組み
- OIDC はその上に認証を載せた仕組み
この記事では、仕様の説明をそのまま並べるのではなく、
実装者がどこで混乱しやすいのか、そして
設計上どこを分けて考えるべきか
に絞って整理します。
先に結論
まず最初に、いちばん大事な整理だけ書きます。
- OAuth は「何をしてよいか」を扱う
- OIDC は「その人が誰か」を扱う
OAuth 2.0 の中心は access token です。
クライアントはそのトークンを使って API や保護リソースへアクセスします。
つまり OAuth の中心テーマは、権限の委譲です。
一方、OIDC では ID Token が追加されます。
クライアントはこの ID Token を検証することで、「認証されたユーザーが誰か」を確認できます。
かなり雑に言うと、こうです。
- OAuth: API を使わせる仕組み
- OIDC: ログインを標準化する仕組み
この違いを曖昧にしたまま実装すると、トークンの扱い、セッション管理、SPA の状態設計が少しずつズレていきます。
なぜ現場では混ざりやすいのか
理由は単純で、ユーザーから見た体験が似ているからです。
たとえば「Googleでログイン」という画面は、見た目だけならただのログインです。
でも内部では OAuth 系のフローが使われ、その上で OIDC が ID Token を返すことで認証結果を扱えるようにしています。
つまり、
画面の見た目は同じでも、内部の責務は同じではない
ということです。
この「体験が似ている」という事実が、OAuth と OIDC を混同しやすくしている最大の理由だと思います。
OAuth 2.0 の本質
access token を使って保護リソースへアクセスする
OAuth 2.0 の本質は、ユーザー本人の表現ではなく、アクセス権限の委譲です。
たとえば、こんなケースです。
- カレンダー API を呼びたい
- 決済 API を利用したい
- 社内 API に scope 付きでアクセスしたい
- 別サービスの保護リソースにユーザーの代わりにアクセスしたい
このとき重要なのは、
- 誰がログインしたか
- その人の名前が何か
よりも、
- どのリソースにアクセスできるか
- 何をしてよいか
です。
つまり OAuth は、ユーザー情報そのものを扱う仕組みではなく、リソースへのアクセス権限を扱う仕組みだと捉えると整理しやすいです。
OIDC の本質
認証結果をクライアントが安全に扱えるようにする
OIDC は、OAuth 2.0 の上に「認証」を載せたものです。
ここで大事なのは、OIDC は単に「ログインできるようにする」ためのものではなく、
認証結果を標準的に扱えるようにするためのものだという点です。
その中心にあるのが ID Token です。
ID Token を使うと、クライアントは少なくとも次のようなことを確認しやすくなります。
- どの認証基盤が発行したか
- どのクライアント向けのトークンか
- 誰が認証されたか
- 認可レスポンスとの整合が取れているか
つまり OIDC は、
「ログインの結果」を設計として扱えるようにする仕組み
だと考えると、かなり腹落ちしやすいです。
access token と ID Token は別物
ここは実装でかなり事故りやすいところです。
access token
API や保護リソースに提示するためのトークンです。
ID Token
クライアントが認証結果を確認するためのトークンです。
この2つを混同すると、よくこんなズレが起きます。
- ID Token を API 認可に使いたくなる
- access token だけでログイン済み判定したくなる
- フロントエンドが「誰なのか」と「何ができるか」を同じ状態で持ちたくなる
でも、本来これは分けるべきです。
誰なのか と 何ができるか は、似ているようで責務が違います。
ここを分けずに持つと、後から状態遷移が複雑になったときに一気につらくなります。
「OAuthでログインできる」は半分正しい
この言い方はよく見ますが、少し雑です。
たしかに、OAuth ベースのフローを使って「ログインっぽい体験」を作ることはできます。
ただし、OAuth 2.0 自体の主眼は認可です。
なので、実務的にはこう捉えるのが分かりやすいです。
- OAuthだけでもログインっぽいことは実現できる
- でも 認証をちゃんと扱いたいなら OIDC を使う方が自然
この整理をしておくと、「なぜ OIDC が必要なのか」が見えやすくなります。
実装フローで見ると、OIDCで何が増えるのか
OAuth 2.0 の Authorization Code Grant をざっくり書くと、流れはこうです。
- クライアントが認可コードを受け取る
- token endpoint から access token を取得する
- その token で保護リソースへアクセスする
OIDC では、この流れの上に ID Token の取得と検証 が乗ります。
さらに必要に応じて UserInfo Endpoint から追加のユーザー情報を取得できます。
つまり OIDC は、OAuth の仕組みを捨てるのではなく、
OAuth の認可フローに認証の意味を足している
という理解がいちばん自然です。
実装者としてどう使い分けるか
1. API 呼び出し権限が主目的なら OAuth
やりたいことが「保護リソースへのアクセス制御」であれば、中心は OAuth です。
このとき考えるべきは、ユーザーのプロフィール取得よりも、
- scope をどう切るか
- どのリソースにアクセスさせるか
- どのクライアントに何を許可するか
といった認可設計です。
2. ログイン機能が主目的なら OIDC
アプリが「誰がログインしたか」を扱い、セッションや本人確認をきちんと設計したいなら、OIDC の方が自然です。
OIDC では ID Token や標準化されたクレームを使えるので、
認証結果を設計として扱いやすいのが強みです。
3. 業務システムの多くは両方使う
実際の業務システムでは、
- ログインも必要
- API 認可も必要
ということが多いです。
この場合は、頭の中でこう分けておくとかなり整理しやすいです。
- ログインは OIDC
- API 認可は OAuth
実装上は同じ認可基盤で動いていても、責務は分けて考えた方が設計が崩れにくいです。
ここまでの整理
最後に、この記事でいちばん伝えたいことだけまとめます。
- OAuth 2.0 は認可
- OIDC は認証
- access token は API のためのもの
- ID Token は認証結果を確認するためのもの
- ログインと API 認可は頭の中で責務を分ける
つまり、実装者目線で大事なのは、
「見た目が同じログイン画面」に引っ張られず、責務とトークンの役割を分けて考えること
です。
おわりに
認証・認可まわりは、用語だけで追うとすぐ混ざります。
でも実装に引きつけると、整理の軸はかなりはっきりします。
- OAuth は「何をしてよいか」
- OIDC は「その人が誰か」
この2つを分けて捉えるだけで、
設計、トークン管理、SPA の状態管理、障害切り分けがかなり楽になります。
認証・認可まわりで混乱したときは、まずこの2つの責務に立ち返るのがいちばん有効だと思います。