OIDCのベストプラクティスを図解解説

Suzuki Hokuto
2025.07.18

はじめに

プラットフォーム開発部でアプリケーション開発を担当している鈴木北斗です。普段の業務では、サービスの認証・認可基盤に触れる機会が多く、特に OIDC はセキュアなアプリケーションを構築する上で欠かせない技術となっています。今回は、その経験から得た知見を基に、OIDC の核心となる認証フローと現在のベストプラクティスを解説していきたいと思います。

概要

現代の Web サービスやアプリケーション開発において、安全で快適なユーザー認証機能は不可欠な要素です。本記事では、その認証を実現する技術として広く採用されている「OpenID Connect (OIDC)」の基本的な概念から、その中核をなす認証フローまでを、図を交えながら分かりやすく解説します。現在の業界標準のベストプラクティスを反映し、クライアントの種類に応じた最も安全な実装方法に焦点を当てています。

1. はじめに – なぜ今、OIDC が重要なのか

複数の Web サービスを利用することが当たり前になった現在、ユーザーはサービスごとに ID とパスワードを管理する必要に迫られています。これはユーザーにとって大きな負担であると同時に、サービス提供者側にとってもパスワード管理は重大なセキュリティリスクを伴います。「Google アカウントでログイン」「LINE でログイン」といったソーシャルログイン機能は、これらの課題を解決する身近な例です。ユーザーは使い慣れたアカウントで新しいサービスに安全かつ簡単にログインできます。この便利なログイン機能の裏側で利用されている代表的な技術が、今回ご紹介するOpenID Connect (OIDC)です。OIDC は、認証における複雑な課題を解決し、ユーザーと開発者の双方に大きなメリットをもたらす、現代の認証技術の標準規格となっています。

2. OpenID Connect (OIDC) とは？

OpenID Connect (OIDC) は、OAuth 2.0 というプロトコルを基盤として作られた、認証のための標準規格です。ここで重要なのは、OAuth 2.0 との関係性です。

OAuth 2.0: 「認可」のためのプロトコルです。あるサービスが、ユーザーの許可を得て、別のサービスのリソース（例: Google ドライブのファイル、Twitter のツイート権限）にアクセスするための仕組みを定めています。「誰か」の証明はせず、あくまで「権限の許可」のみを扱います。

OIDC: OAuth 2.0 の認可フローの上に「認証」の層を追加したものです。「このユーザーは誰か」を証明し、その情報を安全にサービス提供者へ連携する仕組みを定めています。つまり、OIDC は OAuth 2.0 を拡張することで、「このユーザーは確かに本人である」という認証を行い、その結果として得られるユーザー情報を連携する機能を実現しています。

3. OIDC の登場人物

OIDC の仕組みを理解するために、まずは主要な登場人物（ロール）を整理しましょう。

ユーザー (User)
サービスを利用したい本人です。エンドユーザーとも呼ばれます。

RP (Relying Party / リライング・パーティ)
ユーザーの認証を必要とする Web サービスやアプリケーションのことです。OIDC による認証結果を利用して、ユーザーにサービスを提供します。

OP (OpenID Provider / オープン ID・プロバイダー)
ユーザーの認証を行い、ID 情報を提供する役割を担います。IdP (Identity Provider) とも呼ばれます。(例: Google, Apple, Microsoft, LINE など) RP は自前で認証機能を持つ代わりに、ユーザーの認証を信頼できる OP に「委託」する、という関係性で成り立っています。

4. OIDC 認証フローの解説：認可コードフロー

OIDC にはいくつかの認証フローが存在しますが、ここでは最も安全で一般的に利用される「認可コードフロー (Authorization Code Flow)」を解説します。

4.1. クライアントの種類とセキュリティ機構の組み合わせ

認可コードフローのセキュリティは、クライアントアプリケーションの種類と、それに適用するセキュリティ機構の組み合わせによって決まります。構成例は以下の通りです。

クライアントタイプ	セキュリティ機構	セキュリティレベル	主な用途 / 備考
コンフィデンシャル	`client_secret` +PKCE	★★★★★(Best Practice)	現在の推奨構成。サーバーサイドアプリで最高のセキュリティを実現。OAuth 2.1の標準。
コンフィデンシャル	`client_secret`のみ	★★★★☆ (Good)	伝統的な構成。多くは安全だが、認可コードインジェクション等のリスクが残る。
パブリック	PKCE	★★★★☆ (Good)	SPAやモバイルアプリの標準構成。`client_secret`を持てない環境での必須要件。
パブリック	なし	★☆☆☆☆ (危険)	非推奨。認可コードが傍受されると、そのままトークンが取得される危険性がある。

次世代仕様のOAuth 2.1では、クライアントの種類を問わず PKCE の使用が必須となるなど、多層的な防御が標準となりつつあります。

4.2. 【推奨】コンフィデンシャルクライアント + PKCE

サーバーサイドアプリケーションにおける、現在の最も安全な実装です。client_secretによるクライアント認証と、PKCE によるセッションの紐付けを両方行い、非常に堅牢なセキュリティを実現します。

▼ 主なステップ

Code Verifier/Challenge 生成: RP のサーバーサイドでcode_verifier（ランダム文字列）と、そのハッシュ値であるcode_challengeを生成します。

認可リクエスト: code_challengeを含めてユーザーを OP の認可エンドポイントにリダイレクトします。

認証と同意: ユーザーが OP で認証を行い、RP に対する権限付与に同意します。

認可コード発行: OP はcode_challengeを紐づけて認可コードを発行し、RP のリダイレクト URI にユーザーをリダイレクトします。

トークンリクエスト: RP のバックエンドサーバーは、認可コード、code_verifier、そして**client_secret** を OP のトークンエンドポイントに送信します。

検証とトークン発行: OP はclient_secretを検証し、さらにcode_verifierとcode_challengeが一致することを確認した上で、ID トークンとAccess Tokenを発行します。

（オプション）ユーザー情報取得: 必要に応じて、発行された Access Token を使用して UserInfo エンドポイントから追加のユーザー情報を取得します。

（オプション）ユーザー情報返却: OP は要求されたユーザー情報を返却します。

4.3. パブリッククライアント + PKCE

ブラウザで動作する SPA（Single Page Application）やモバイルアプリの標準的な実装です。

client_secretを安全に保持できないため、PKCE が必須となります。

▼ 主なステップ

Code Verifier/Challenge 生成: RP（ブラウザ上のアプリ）でcode_verifier（ランダム文字列）と、そのハッシュ値であるcode_challengeを生成します。

認可リクエスト: code_challengeを含めてユーザーを OP の認可エンドポイントにリダイレクトします。

認証と同意: ユーザーが OP で認証を行い、RP に対する権限付与に同意します。

認可コード発行: OP はcode_challengeを紐づけて認可コードを発行し、RP のリダイレクト URI にユーザーをリダイレクトします。

トークンリクエスト: RP は、認可コードとcode_verifierを OP のトークンエンドポイントに送信します。（client_secretは使用しません）

検証とトークン発行: OP はcode_verifierとcode_challengeが一致することを確認し、ID トークンとAccess Tokenを発行します。

ユーザー情報取得: 必要に応じて Access Token を使用して UserInfo エンドポイントから追加のユーザー情報を取得します。

5. ID トークンと UserInfo エンドポイント

OIDC の特徴は、認証の結果としてID トークンを発行することです。

ID トークンとは

ID トークンは、ユーザーの認証情報を含む JWT（JSON Web Token）形式のトークンです。以下のような特徴があります：

デジタル署名済み: OP の秘密鍵で署名されており、改ざんを検出できます

自己完結型: トークン自体にユーザー情報（クレーム）が含まれています

有効期限付き: 通常は短時間（15 分〜1 時間程度）で失効します

主なクレーム（Claims）

ID トークンには以下のような標準的なクレームが含まれます：

{
  "iss": "https://accounts.google.com", // 発行者 "sub": "110169484474386276334",        // 発行者(iss)内で一意なユーザー識別子
  "aud": "your-client-id",               // 対象クライアント
  "exp": 1516239722,           // 有効期限
  "iat": 1516236122,           // 発行時刻
  "email": "user@example.com", // メールアドレス
  "name": "田中太郎",                     // 表示名
  "picture": "https://...",              // プロフィール画像URL
  "email_verified": true                 // メール認証済みフラグ
}

UserInfo エンドポイント

追加のユーザー情報が必要な場合は、Access Token を使用して UserInfo エンドポイントからより詳細な情報を取得できます。これにより、ID トークンのサイズを適切に保ちながら、必要に応じて追加情報を取得する柔軟性を提供します。

6 セキュリティ上の重要なポイント

OIDC 実装において、以下のセキュリティ対策は必須です。

HTTPS の徹底

全ての通信は HTTPS で行う必要があります。
特にリダイレクト URI は厳格に検証されます。

state パラメータによる CSRF 対策

認可リクエストにはstateパラメータを含め、CSRF 攻撃を防止します
PKCE と組み合わせることでより強固なセキュリティを実現します

ID トークンの検証

ID トークンの署名検証は必須です
iss（発行者）、aud（対象）、exp（有効期限）の検証を行います
nonceパラメータによるリプレイ攻撃対策も重要です

リダイレクト URI の厳格な管理

OP 側で登録されたリダイレクト URI と完全一致する必要があります
ワイルドカードの使用は避けるべきです

7. OIDC を導入するメリット

弊社がお客様のシステム開発において OIDC の導入をご提案・実装するのは、以下のような明確なメリットがあるためです。

セキュリティの向上 認証機能を、セキュリティ対策の専門家である OP（Google など）に集約できます。サービス提供者は、最も漏洩リスクの高いパスワード情報を自社で保持・管理する必要がなくなります。 OP が提供する多要素認証（MFA）などの高度なセキュリティ機能を、ユーザーはそのまま利用できます。

ユーザー体験 (UX) の向上 ユーザーは新しいサービスごとに ID とパスワードを作成・記憶する必要がなくなります。シングルサインオン（SSO）環境を構築しやすく、一度の認証で複数の連携サービスをシームレスに利用可能になります。

開発・運用コストの削減 複雑で責任の重い認証機能を自前で実装・保守する必要がなくなります。実績のあるライブラリや OP を利用することで、堅牢な認証基盤を迅速に導入できます。弊社では、この導入メリットを最大化し、お客様のビジネス要件に合わせた最適な認証基盤の設計・構築を支援しています。

8. まとめ

OIDCは、単なるログイン機能に留まらない、Web全体のセキュリティと利便性を向上させる重要な基盤技術です。その仕組みは一見複雑に見えますが本質を理解することで、より堅牢なアプリケーションを設計できます。弊社ではこうした標準技術を深く理解し、安全で質の高いサービスを開発することを常に心がけています。この記事が皆さんのセキュアなサービス開発の一助となれば幸いです。