この記事は デジタル創作サークル UniProject Advent Calendar 2025 1 日目の記事です。
学び始める経緯
私はデジタル創作サークル UniProject なるサークルを運営しています。
サークル内では、以下のようなシステムを運用しています。
- GROWI
- Kubernetes
- Proxmox
- etc...
メンバーが 100 人ほどになってきたわけですが...とにかくアカウントが分かれていて管理がめんどくさいという問題に直面しました...
考えた案
SAML
- ちょっとレガシーすぎる...
- XML で通信するのがちょっとしんどい
- OAuth はいじったことあるけど SAML はいじったことない
Open ID Connect (以下 OIDC)
- なんか OAuth の拡張らしい
- OAuth いじってきたから簡単そう~~(フラグ)~~
- GROWI も K8s も Proxmox も対応してる
ということで、OIDC に決まりました。
とはいえ、OIDC と OAuth の違いすらわからず...まずは双方を調べてみることにしました。
OAuth ってなんぞや
まず、OIDC が OAuth の拡張らしいということはわかったので、まず OAuth をしっかりと理解しようと文献を読み漁りました。
アクセストークン
OAuth 2.0 で発行されるのは、アクセストークンであり、これを用いることで、サーバーへアクセスできるようになるということがわかりました。
OIDC ってなんぞや
まず、OIDC がなんたるかという話になり、RFC を生で読み始めました。
日本語の文献がとにかく少なく、人づてに聞いたり、頑張ってまずは理解しようとしました...
認証と認可
まず、OIDC は認証の規格であり、OAuth2.0 は認可の規格であることを知りました。
ここでまず、認証と認可の違いってなんぞやというところを理解するのに苦しみました。
認証
認証は、いわゆる**あなた誰ですか?**という話です。
まずアクセスしようとしてきた人が本当にその本人かどうかを確かめるということですね。
身分証チェックに似た話です。
認可
認可は、**あなたにアクセスする権限はあるの?**というチェックです。
例えばお酒を買う時。免許証を出してもらい、顔写真と照らし合わせてまず本人かを確認します(認証)。
そこで本人だとわかったとしても、20 歳未満であった場合はお酒を買う許可がありません。
この、あなたにその許可・権限がありますか?という確認が認可です。
ID トークン
OIDC では、ID トークンを発行します。この ID トークンには、ユーザーの情報が詰まっています。
様々なフロー
このトークンの取得には様々なフローがあります。
Implicit Flow
クライアントが直にアクセストークンを受け取り保持する方式です。
これはミスるとトークン置き換え攻撃の温床になります。
Authorization Code Flow
バックエンドサーバーがトークンを受け取る方法です。
トークン置き換え攻撃
OAuth は認可の規格であり、それで認証を行うことはできません。
というか、してはならないのです。1
その理由の一つがトークン置き換え攻撃です。
Public Client とも呼ばれますが、ネイティブアプリケーションやモバイルアプリケーションは、クライアントサイドでアクセストークンを保持し、サーバーサイド(バックエンド)で受け取ることはありません。
クライアントサイド → バックエンドへとアクセストークンを送信すると何が起こるか、「●● でログイン」しようとしたリソースオーナーのアクセストークンであることが保証できなくなるのです。
要するに、Access Token を置き換えることで悪意あるユーザーとして認証させて「乗っ取らせ」を行いユーザー情報を登録させるなどのセキュリティホールを生む可能性があります。
これの対策として、Access Token の置き換えの口をつくらないこと、受け取った Token の発行対象のクライアントを検証することなどが挙げられますが、そんなものは OAuth には定義されていません。
アクセストークンがどの RP (Relying Party、アプリケーションのこと)に対して発行されたものかを検証する術はありません。
ですが、OIDC の ID トークンでは、どの RP に対して発行したかという情報が署名付きの JWT に保存されているので、検証することができます。
最後に
今回は OAuth2.0 とそれを拡張した OIDC の違いについて見てみました。
当サークルでは、この OIDC を活用したサークル内認証基盤を構築中です。
もし興味がありましたら、下記リンクからご参加いただけますと幸いです!
⭐︎ 公式 HP ↓
⭐︎ 公式 Discord サーバー ↓
-
GitHub や Twitter、Facebook などは、OAuth を独自に拡張して安全に OAuth だけで認証できるようにしていますが、これは例外なのでここでは割愛します。 ↩

