OIDC入門：モバイル時代に最適化された認証と認可の仕組み

🌟 はじめに

OIDC（OpenID Connect）は、Webサービスやモバイルアプリにおいて認証（Authentication）と認可（Authorization）を効率的に実現するためのプロトコルです。
SAMLがエンタープライズWebアプリを中心に普及したのに対し、OIDCはREST/JSONをベースとし、クラウドネイティブ・モバイル環境に強みを持ちます。
この記事では、OIDCの誕生背景、仕組み、利用のメリット・デメリット、そして代表的なユースケースを整理します。

📜 歴史的背景 ― SAMLからOIDCへ

SAMLの課題

XMLベースで複雑、実装が重い
主にブラウザリダイレクトを前提としており、モバイルアプリやAPIとの相性が悪い

OAuth 2.0の登場

2010年、リソースへの**認可（Authorization）**を安全に行うための仕組みとしてOAuth 2.0が登場
例：GoogleやFacebookアカウントで他サービスに「ログイン連携」する

OpenID Connectの登場

2014年、OAuth 2.0を拡張して「認証（Authentication）」機能を統合したのがOIDC
JSONとREST APIベースで、軽量かつシンプルな実装が可能になった

🔑 OIDCの基本概念

主な登場人物

ユーザ（End-User）：サービスを利用する人
RP（Relying Party, クライアントアプリ）：ログイン機能を利用したいアプリやサービス
IdP（Identity Provider, OpenID Provider, OP）：ユーザの認証を担当するサービス（Google, Microsoft, Auth0など）

トークンの種類

IDトークン：ユーザの認証情報を含むJWT（JSON Web Token）
アクセス・トークン：リソースAPIへのアクセス権を示す
リフレッシュ・トークン：長期利用のために新しいアクセス・トークンを発行する

OIDCのIDトークンはJWT形式のため、人間でも中身をBase64デコードすれば「誰か」「どのIdPから発行されたか」を確認できる。

🔄 動作フロー（Authorization Code Flow の例）

ユーザがRP（アプリ）にログイン要求
RPはIdPにリダイレクトし、ユーザが認証
IdPが認可コードをRPへ返す
RPは認可コードをIdPに送信してIDトークンとアクセス・トークンを取得
RPはIDトークンを検証し、ユーザが誰かを確認
必要に応じてアクセス・トークンでAPIを呼び出し

この方式では認証情報（パスワード等）がRPに渡らないため、セキュリティが高く保たれる。

🎯 OIDCを使うメリット

軽量かつシンプル：JSON/RESTベースで開発者に扱いやすい
モバイル・API連携に強い：アプリやマイクロサービスでも自然に利用可能
広範な普及：Google, Microsoft, Amazon など主要クラウドが標準対応
認証と認可の統合：OAuth 2.0に加えて「ログイン」も実現できる

⚠️ 課題・デメリット

仕様の柔軟さ：OAuth 2.0ベースのため、実装のバリエーションが多く混乱を招きやすい
トークン管理リスク：IDトークン・リフレッシュトークンの漏洩は不正利用に直結
SAMLとの互換性不足：古いエンタープライズ環境ではSAMLが主流であり、OIDCへの移行にコストがかかる

「Implicit Flow」など一部の古いフローは脆弱性が指摘されており、現在はAuthorization Code Flow + PKCEが推奨される。

🏢 代表的なユースケース

GoogleログインやMicrosoftアカウントでのSSO
モバイルアプリ認証（ネイティブアプリのログイン機能）
API Gatewayとの連携：マイクロサービス環境でのセキュアなAPI利用
BtoCサービス：ユーザが外部アカウントを使って簡単に新規登録・ログイン

🔮 今後の展望

OIDCはすでにクラウドネイティブやモバイルの「標準的な認証基盤」として定着しています。
SAMLがエンタープライズの歴史的遺産を支える一方で、新規システムの大半はOIDCを前提として設計される傾向が強まっています。
将来的にはFIDO2やパスキーと組み合わせ、さらに安全かつパスワードレスな世界が広がっていくと予想されます。

✅ まとめ

OIDCはOAuth 2.0をベースにした認証＋認可の仕組み
JSON/RESTベースでモバイルやクラウド環境に最適
IDトークンを用いることで、誰がログインしたかを安全に確認可能
新規サービスではOIDCがデファクトスタンダードになりつつある