OAuthとOIDCの違いをわかりやすく解説！混乱しがちな認証・認可の基礎を徹底整理

---

OAuthとOIDCの違いを理解するための基礎

OAuthとOIDCは現代のウェブ・モバイルアプリの安全性を担保するための基本技術です。
OAuthは「認可」を実現する枠組みであり、OIDCはそのOAuthの枠組みを使いながら「認証」も担えるよう拡張した仕組みです。
つまりOAuthは、ユーザーのパスワードを第三者に渡さずに「このアプリにこの範囲の権限を与える」という許可を渡すための道具です。一方OIDCは、同じ道具を使いながら「この人が誰なのか」を証明する情報を一緒に提供します。
この違いを正しく理解することは、システム設計の基礎として非常に大切です。
本稿では、まずOAuthの基本的な考え方、次にOIDCの追加機能、最後に実務での選択ポイントを、分かりやすく丁寧に解説します。
読み進めるうちに、「どの場面で何を渡すべきか」「どんなトークンが返ってくるのか」が自然と見えてきます。
なお、セキュリティの観点からは、最小権限の原則、トークンの有効期限管理、PKCEの導入なども合わせて押さえることが重要です。
この理解があれば、部品を組み合わせて安全な認証・認可の設計を自信を持って進められます。

OAuthとは何か

OAuthは、ユーザーのパスワードを第三者アプリへ渡さずに、ユーザーの代わりにリソースへアクセスする権限を第三者に渡す仕組みです。
この仕組みの中核には四つの役割があります。
Resource Owner（資源所有者）＝ユーザー、Client（クライアント）＝アプリ、Authorization Server（認可サーバー）、Resource Server（資源サーバー）です。
動作の流れはこうです。まずユーザーがアプリにアクセスして認可を求め、アプリは認可サーバーへ「このリソースに対するこの程度の権限を付与してほしい」というリクエストを送ります。ユーザーが同意すると、認可サーバーは一時的なコードまたはトークンを返します。アプリはこのトークンを使って保護されたリソースへアクセスします。
この過程でパスワードは一切渡りません。
実務では、Authorization Code Grant、Implicit、Client Credentials、Resource Owner Password Credentialsなど複数のフローがあり、用途に応じて使い分けます。
セキュリティの観点からは、短寿命のアクセストークン、リフレッシュトークンの適切な運用、CORS対策、CSRF対策、PKCE（Proof Key for Code Exchange）の導入が重要です。
特にモバイルアプリやシングルページアプリ（SPA）ではPKCEの利用が強く推奨されます。
OAuth自体は「誰に何の権限を渡すか」を管理する枠組みであり、認証情報の本人確認を直接担当するものではありません。

OIDCとは何か

OIDCはOAuth 2.0の枠組みを利用して「誰がログインしているのか」を証明する認証の機能を追加した標準です。
OIDCはID Tokenと呼ばれるJWT形式のトークンを返し、sub（主な識別子）、name、email、pictureなどのクレームを含みます。
さらに、追加のユーザー情報を取得するためのUserInfoエンドポイントを提供します。
OIDCの流れもOAuthと似ていますが、認証情報を取り扱うための追加ルールと仕様が加わっています。
この仕組みを使えば、外部IDプロバイダーを利用したサインインを一貫した方法で実現でき、アプリのサインイン体験を統一できます。
また、セッション管理・ログアウト連携・多要素認証との組み合わせも容易で、セキュリティとUXの両方を高められます。
実務ではAuthorization Code with PKCEなどの安全なフローを採用し、IDトークンとアクセス・リフレッシュトークンを組み合わせて運用します。OIDCを採用することで、単純な「誰かを認証する」だけでなく、現代的な認証体験の設計が可能になります。

OAuthとOIDCの違いを表で見る

ここでは主な違いを表で整理します。理解を深めるために、役割・トークン・目的・利用シーンの4点を比較します。
表を見れば、何をどの場面で使うべきかがはっきり分かるようになります。
また、混同を避けるために両者の関係性を意識して読み進めてください。

able>項目OAuth 2.0OIDC目的認可（リソースへアクセスする権限を第三者へ渡す）認可に加えて認証（誰が利用しているかの確認）を行う返されるトークンAccess Token、場合によってはRefresh TokenID Token + Access Token（必要に応じてRefresh Token）ユーザー情報基本的には無し。リソースサーバーの情報は別経路で取得されることが多いUserInfoエンドポイントで追加情報を取得可能標準化の性質OAuth 2.0の仕様のみOIDCが追加の仕様（ID Token等）を提供代表的なフローAuthorization Code、Client Credentials、Implicit などAuthorization Code with PKCE、Hybridなどを安全に選択ble>

ピックアップ解説

昨日友達とカフェでOAuthとOIDCの話をしていて、私たちは“本当に大事なのは認証と認可の区別をつけること”だと痛感しました。OAuthは“誰に何を渡すか”を管理する道具で、OIDCはその道具を使って“この人が誰か”を証明するための追加機能をつけた拡張です。認証が必要な場面と、ただの権限付与だけで十分な場面を区別し、PKCEなどの安全なフローを選ぶことが大切だと感じました。話を深めるうちに、ID Tokenがどう動くか、UserInfoエンドポイントがどんな情報を返すのか、そして実装上の注意点（セッション管理、ログアウト連携、トークンの有効期限など）も自然と見えてきました。結局は“使う場面に応じた最適な組み合わせを選ぶこと”が、セキュリティとユーザー体験を両立させる秘訣なのだと再確認しました。

---