「OAuth」と「OpenID Connect」の違いとは？認可・認証・IDトークンを解説

「OAuthでログインする」

「OpenID Connectでユーザー認証する」

WebサービスやAPIについて調べていると、「OAuth」と「OpenID Connect」というよく似た言葉が登場します。

どちらもGoogleやMicrosoftなどのアカウント連携で利用されるため、

「OAuthとOpenID Connectは同じもの？」

「GoogleでログインはOAuth？」

「OAuthは認証ではないの？」

「アクセストークンとIDトークンは何が違う？」

「OpenID ConnectはOAuthの新しいバージョン？」

と迷うことがあります。

結論からいうと、「OAuth 2.0」は、アプリに限定的なアクセス権を与えるための「認可」の仕組みです。一方、「OpenID Connect」はOAuth 2.0の仕組みを基盤として、利用者が誰なのかを確認する「認証」の機能を追加したプロトコルです。

一言で覚えるなら、

OAuth＝「このアプリに何を許可する？」

OpenID Connect＝「ログインしたこの人は誰？」

です。

たとえば、ある写真印刷アプリが、あなたのクラウドストレージに保存されている写真だけを読み取りたいとします。

このとき、

「このアプリに写真の読み取りを許可する」

という処理の中心になるのがOAuthです。

一方、Webサービスに、

「Googleアカウントでログインして、この利用者が誰なのか確認する」

という目的で使われるのがOpenID Connectです。

IETFのRFC 6749はOAuth 2.0を、第三者アプリケーションへHTTPサービスに対する限定的なアクセスを与える「Authorization Framework」と定義しています。

OpenID FoundationはOpenID Connectについて、OAuth 2.0の上に構築された「Identity Layer」であり、クライアントが認証されたエンドユーザーの身元を確認できる仕組みと説明しています。

この記事では、「OAuth」と「OpenID Connect」の違いから、認証・認可、アクセストークン、IDトークン、スコープ、Authorization Code、PKCE、「Googleでログイン」の仕組みまで詳しく解説します。

「OAuth」と「OpenID Connect」の違い【結論】

比較項目	OAuth 2.0	OpenID Connect
主な目的	認可	認証
答える疑問	「何へのアクセスを許可する？」	「ログインした利用者は誰？」
基盤	OAuth 2.0そのもの	OAuth 2.0を基盤に拡張
代表的なトークン	Access Token	ID Token＋Access Tokenを利用する場合がある
ユーザー本人の識別	OAuth 2.0単独では標準化された目的ではない	ID Token等で標準化
代表的な用途	外部アプリへのAPIアクセス許可	外部アカウントを使ったログイン・ID連携
重要なscope	APIごとのscope	openid

3秒で判断するなら、

「外部アプリにデータへのアクセスを許す？」 → OAuth

「その利用者が誰か確認してログインさせる？」 → OpenID Connect

と考えると分かりやすいでしょう。

そもそも「OAuth 2.0」とは？

パスワードを渡さず、限定的なアクセス権を与える仕組み

OAuth 2.0は、ユーザーが利用するサービスのパスワードを第三者アプリへ教えることなく、限定的なアクセス権を与えるための認可フレームワークです。

たとえば、写真加工アプリがクラウドストレージの写真を読み取りたいとします。

昔ながらの単純な方法なら、利用者がクラウドサービスのIDとパスワードを写真加工アプリへ渡す必要があるかもしれません。

しかし、それでは第三者アプリが利用者の認証情報そのものを知ることになり、危険です。

OAuthでは、パスワードを渡す代わりに、

「このアプリには、写真の読み取りだけを許可する」

といった形で限定的な権限を与えられます。

OAuthの中心は「認可」

OAuthを理解するうえで最も重要なのが、

OAuth＝認可

という点です。

認可とは、

「誰に、どのリソースへの、どの操作を許すか」

を決めることです。

たとえば、

• 写真を読む
• 予定表を読む
• ファイルを書き込む
• プロフィール情報を取得する

など、アプリへ許可する範囲を限定できます。

OAuthに登場する主な役割

OAuth 2.0では、主に次のような役割が登場します。

役割	意味
Resource Owner	保護されたデータへのアクセスを許可できる主体。人の場合はエンドユーザー
Client	データへアクセスしたいアプリ
Authorization Server	認可を処理し、トークンを発行するサーバー
Resource Server	保護されたAPI・データを提供するサーバー

たとえば、カレンダー連携アプリがユーザーの予定表を読み取る場合、カレンダーサービスのAuthorization Serverから適切なアクセストークンを取得し、それを使ってResource ServerのAPIへアクセスします。

「アクセストークン」とは？

OAuthで特に重要なのが、

Access Token（アクセストークン）

です。

アクセストークンは、クライアントが保護されたリソースへアクセスするために利用する資格情報です。

簡単にいえば、

「このアプリには、この範囲のAPI利用が許可されている」

ことを示すために使われます。

たとえば、写真サービス用のアクセストークンに「写真を読む」という権限が与えられていれば、アプリはそのトークンを提示して写真APIへアクセスできます。

アクセストークンは「ユーザーの身分証明書」ではない

ここは非常に重要です。

アクセストークンは、基本的に、

APIなどの保護されたリソースへアクセスするためのもの

です。

OAuth 2.0の仕様だけでは、アクセストークンを使って、

「この利用者の氏名は何か」

「誰がログインしたのか」

を標準的な方法でアプリへ伝える仕組みは定められていません。

OpenID Connect Coreも、OAuth 2.0はリソースへアクセスする仕組みを定めている一方、エンドユーザーの認証情報を標準化して提供するものではないと説明しています。

「OpenID Connect」とは？

OAuth 2.0へ「ユーザー認証」を追加した仕組み

OpenID Connectは、

OIDC

と略されます。

OpenID Foundationは、OpenID Connect 1.0を、

OAuth 2.0プロトコルの上に構築されたシンプルなIdentity Layer

と定義しています。

OpenID Connectを利用すると、クライアントアプリは、Authorization Serverが行った認証結果を基に、

「どのエンドユーザーが認証されたのか」

を確認できます。

OAuthだけでは足りなかった「ログイン」の部分を補う

OAuth 2.0は、

「外部アプリに何を許すか」

を扱うのが主目的です。

しかしWebサービスでは、

「Googleなど別サービスのアカウントを使って自分のサービスへログインさせたい」

という需要もあります。

そこでOAuth 2.0の仕組みを基盤としながら、ユーザーの本人確認方法を標準化したのがOpenID Connectです。

OpenID Connectでは「openid」が重要

OpenID Connectの認証リクエストでは、

openid

というscope値が重要です。

OpenID Connect Coreでは、Authorization Requestのscopeに、

openid

が含まれていなければ、OpenID Connectリクエストとしては扱われないと定めています。

つまり、

scope=openid

が、OAuth 2.0の認可処理へOpenID Connectによる認証機能を加える重要な目印になります。

「IDトークン」とは？

OpenID Connectで最も特徴的なのが、

ID Token（IDトークン）

です。

IDトークンは、

「このユーザーが認証された」

という情報をクライアントへ伝えるためのトークンです。

OpenID Connectでは、IDトークンを、認証されたエンドユーザーに関するClaimsを含むJWTとして定義しています。

代表的なClaimsには、

• iss：誰がIDトークンを発行したか
• sub：ユーザーを識別する識別子
• aud：どのクライアント向けか
• exp：有効期限
• iat：発行時刻

などがあります。

アクセストークンとIDトークンの違い

比較項目	アクセストークン	IDトークン
主な規格	OAuth 2.0	OpenID Connect
主な目的	API・リソースへのアクセス	認証結果・ユーザーID情報をクライアントへ伝える
主な受け手	Resource Server	Client / Relying Party
APIアクセスに使う？	使う	通常、APIアクセス用として使わない
ログインしたユーザー確認	それ自体を目的にしない	目的の一つ

覚え方としては、

Access Token＝「APIに何をさせてもらえるか」

ID Token＝「誰がログインしたか」

と整理すると分かりやすいでしょう。

IDトークンでAPIへアクセスしてよい？

原則として、IDトークンとアクセストークンの役割を混同しないことが重要です。

IDトークンは、クライアントがユーザーの認証結果を確認するためのものです。

APIなどのResource Serverへアクセスするときには、そのAPI向けに発行されたアクセストークンを利用します。

「どちらもトークンだから自由に交換できる」

わけではありません。

アクセストークンをログイン判定に使ってよい？

OAuth 2.0のアクセストークンを、単純にユーザー本人確認用のトークンとして扱うのは適切ではありません。

アクセストークンはResource Serverへ提示するための資格情報であり、クライアント自身へユーザーの認証結果を伝える目的で設計されたものではありません。

ユーザー認証には、OpenID ConnectのIDトークンなど、認証目的の仕組みを利用します。

「Googleでログイン」はOAuth？OpenID Connect？

Googleの公式資料では、Webサイトに「Googleでログイン」を提供する際、Google Identity Servicesが、

OpenID Connectプロトコルを基盤とするIDトークン

を提供すると説明されています。

Googleの認証処理では、OAuth 2.0の仕組みを利用しつつ、OpenID Connectによってユーザーの身元を確認します。

つまり、単純に、

「Googleでログイン＝OAuthだけ」

と表現するより、

「OAuth 2.0を基盤としたOpenID Connectによる認証」

と理解するほうが正確です。

OAuthとOpenID Connectは「どちらか一方」ではない

OAuthとOpenID Connectは競合する規格ではありません。

OpenID ConnectはOAuth 2.0の認可フローを利用し、その上に認証用の機能を追加しています。

そのため、一つの処理の中で、

• ユーザーを認証する
• ユーザー情報を取得する
• APIへのアクセス権限を取得する

といった機能を組み合わせることがあります。

GoogleのOpenID Connect実装でも、認証フローからIDトークンとアクセストークンの両方が返される場合があります。

OpenID ConnectとOAuthの関係を図式化すると？

簡略化すると、

OAuth 2.0

↓

認可の仕組み

↓

OpenID Connectが認証用のIdentity Layerを追加

という関係です。

したがって、

OpenID Connect＝OAuth 2.0を置き換える別規格

ではありません。

「Authorization Code」とは？

OAuth 2.0・OpenID Connectでよく登場するのが、

Authorization Code（認可コード）

です。

Authorization Code Flowでは、ユーザーが認可サーバーで認証・同意などを行った後、クライアントへ短時間だけ利用する認可コードが返されます。

クライアントはそのコードをToken Endpointへ送り、アクセストークンなどと交換します。

OpenID ConnectのAuthorization Code Flowでは、条件に応じて、

• Access Token
• ID Token
• Refresh Token

などが発行されます。

「PKCE」とは？

PKCEは、

Proof Key for Code Exchange

の略です。

Authorization Codeが途中で盗まれ、攻撃者に不正利用されるリスクを減らすための仕組みです。

2025年に公開されたOAuth 2.0 Security Best Current Practice（RFC 9700）では、Public ClientはAuthorization Codeを保護するためPKCEを使用することが必須とされ、Confidential Clientでも利用が推奨されています。

現在OAuthを実装するときは、古い実装例だけでなく、RFC 9700など最新のセキュリティ推奨事項を確認することが重要です。

「Scope」とは？

OAuthのScopeは、クライアントが要求するアクセス範囲を表します。

たとえば、

• 予定表を読む
• 写真を読む
• プロフィール情報を取得する

などです。

OpenID ConnectでもOAuthのScopeの仕組みを利用します。

特に、

openid

を指定することでOpenID Connectによる認証を要求します。

さらに、

• profile
• email
• address
• phone

などのScopeで、追加のClaimsを要求できます。

「Claims」とは？

Claimsは、ユーザーなどに関する情報を、

「名前＝値」

の形式で表すものです。

たとえば、

• sub：ユーザー識別子
• name：氏名
• email：メールアドレス
• email_verified：メールアドレス確認済みか

などです。

OpenID Connectでは、IDトークンやUserInfo Endpointなどを通してClaimsを取得できます。

「UserInfo Endpoint」とは？

OpenID Connectでは、認証されたユーザーについて追加情報を取得する、

UserInfo Endpoint

が定義されています。

UserInfo EndpointはOAuth 2.0のProtected Resourceとして扱われます。

クライアントはOpenID Connect認証で取得したアクセストークンを提示し、許可された範囲のユーザー情報を取得します。

つまり、

IDトークン＝認証結果を伝える

アクセストークン＝UserInfoなどのAPIへアクセスする

という役割分担を見ることができます。

「Consent（同意）」と認証は同じ？

違います。

OAuthでは、ユーザーが、

「このアプリに予定表の読み取りを許可しますか？」

といった画面で同意を求められることがあります。

これは主に認可に関係する処理です。

一方、

「この利用者は本人である」

と確認するのが認証です。

一つの画面遷移の中に認証と同意が連続して現れることがあるため、両者を混同しやすくなります。

「OAuthでログイン」という表現は間違い？

一般会話や製品説明では「OAuthログイン」と呼ばれることがあります。

しかし、OAuth 2.0自体は認可フレームワークです。

ユーザーのログイン・ID連携を標準的に扱うのであれば、OpenID Connectなどの認証プロトコルを利用します。

そのため技術的な説明では、

「OAuthを使ったログイン」

という表現だけでは、実際にどの方式でユーザー認証を行っているのか不明確になります。

OpenID Connectは「OpenID 2.0」と同じ？

同じではありません。

OpenID Connectは、以前存在したOpenID 2.0をそのまま拡張したものではなく、OAuth 2.0を基盤として設計された別のプロトコルです。

名称が似ているため混同しないよう注意が必要です。

OAuth 2.0とOAuth 2.1の違いは？

OAuth 2.1は、OAuth 2.0とその後に蓄積されたセキュリティ上の推奨事項を整理・統合する次世代仕様としてIETFで作業されています。

2026年9月時点では、IETF Datatracker上でOAuth 2.1はまだInternet-Draftとして扱われており、正式なRFCとして公開された状態ではありません。

一方、OAuth 2.0については、2025年1月にRFC 9700「Best Current Practice for OAuth 2.0 Security」が公開され、現在の安全な実装に関する重要な推奨事項が示されています。

現在はImplicit Flowを使ってよい？

古いOAuth・OpenID Connectの記事では、Implicit Flowが紹介されている場合があります。

しかしRFC 9700は、OAuth 2.0のImplicit Grantを利用すべきではないとしています。

また、Resource Owner Password Credentials Grantも利用してはならないとしています。

そのため、OAuthを学習・実装するときは、古い解説だけで判断せず、現在のセキュリティBCPを確認することが重要です。

「OAuth・OpenID Connect」で迷ったときの3秒判定

こんな場合	答え
アプリにAPIへのアクセスを許可する	OAuth
外部アカウントでユーザーをログインさせる	OpenID Connect
Access Tokenを発行する	OAuthで中心的に利用
ID Tokenを発行する	OpenID Connect
scopeにopenidを含める	OpenID Connect
APIへの権限範囲を指定する	OAuth
認証された利用者のsubを確認する	OpenID Connect

最も簡単に覚えるなら、

OAuth＝「権限を渡す」

OpenID Connect＝「本人を確認する」

です。

「OAuth」を使った例文

• OAuthを使って外部アプリに予定表へのアクセスを許可する。
• OAuth 2.0のアクセストークンをAPIへ送信する。
• アプリが要求するOAuthのScopeを確認する。
• OAuthでユーザーのパスワードを第三者アプリへ渡さずにアクセス権を与える。
• OAuthのAuthorization Code Flowを利用する。

「OpenID Connect」を使った例文

• OpenID Connectを使ってユーザーを認証する。
• OpenID ConnectのIDトークンを検証する。
• GoogleのOpenID Connect機能を利用してログインする。
• Authorization Requestにopenid Scopeを追加する。
• OpenID ConnectのUserInfo Endpointからプロフィール情報を取得する。

具体例で比較：写真アプリにアクセスを許可

写真加工アプリが、クラウドストレージに保存されている写真を読み取りたいとします。

利用者が、

「写真の読み取りを許可」

すると、アプリはその権限を持つアクセストークンを取得し、写真APIへアクセスします。

ここで中心となるのは、

OAuthによる認可

です。

具体例で比較：GoogleアカウントでWebサービスへログイン

あるWebサービスで「Googleでログイン」を選択したとします。

Webサービス側が知りたいのは、

「Google側で認証されたユーザーが誰なのか」

です。

GoogleのOpenID Connect実装では、クライアントはIDトークンを受け取り、署名・発行者・Audience・有効期限などを検証したうえでユーザーを識別します。

この部分が、

OpenID Connectによる認証

です。

具体例で比較：ログインとAPIアクセスを同時に使う

あるアプリでGoogleアカウントによるログインを行い、その後Google側の特定APIにもアクセスするとします。

この場合、

IDトークン → ユーザー認証

アクセストークン → 許可されたAPIアクセス

という形で、OpenID ConnectとOAuthの両方の機能を利用することがあります。

つまり両者は、現実のシステムでは一緒に利用されることが多いのです。

よくある間違い1：「OAuthとOpenID Connectは同じ」と思う

同じではありません。

OAuthは認可、OpenID ConnectはOAuth 2.0を基盤にした認証の仕組みです。

よくある間違い2：「OAuthはログイン規格」だと思う

OAuth 2.0単独の主目的はログイン認証ではありません。

外部アプリへ限定的なアクセス権を与える認可フレームワークです。

よくある間違い3：「アクセストークンがあればユーザー本人だと分かる」と思う

アクセストークンは基本的にResource Serverへのアクセス用です。

ユーザー認証にはIDトークンなど、認証目的で定義された仕組みを使います。

よくある間違い4：「IDトークンでAPIへアクセスする」と思う

IDトークンはクライアントが認証結果を確認するためのものです。

APIアクセスには、そのResource Server向けのアクセストークンを利用します。

よくある間違い5：「OpenID ConnectはOAuthの後継バージョン」と思う

違います。

OpenID ConnectはOAuth 2.0を基盤に認証機能を追加したプロトコルで、OAuthを置き換えるものではありません。

よくある間違い6：「openidはユーザー名」と思う

OpenID Connectで使う「openid」は、認証を要求するためにScopeへ指定する特別な値です。

ユーザーそのものを識別する代表的なClaimは「sub」です。

よくある間違い7：「古いOAuthの実装例でも現在そのまま使える」と思う

OAuthのセキュリティ上の推奨事項は更新されています。

RFC 9700ではImplicit GrantやResource Owner Password Credentials Grantなど、以前使われていた一部方式を使用しないよう明確にしています。

「OAuth」と「OpenID Connect」に関するよくある質問

Q1. OAuthとOpenID Connectの一番簡単な違いは？

OAuthは「何へのアクセスを許すか」を扱う認可、OpenID Connectは「誰がログインしたか」を扱う認証です。

Q2. OpenID ConnectはOAuthを使っていますか？

はい。

OpenID ConnectはOAuth 2.0の上にIdentity Layerを追加した仕組みです。

Q3. OAuthだけでログイン機能を作れますか？

OAuth 2.0単独はユーザー認証の標準ではありません。

外部アカウントによるログインを標準的に実装する場合は、OpenID Connectなど認証を目的として設計された仕組みを利用します。

Q4. アクセストークンとIDトークンは同じですか？

違います。

アクセストークンは保護されたAPIへのアクセスに、IDトークンはクライアントがユーザー認証の結果を確認するために使われます。

Q5. IDトークンは必ずJWTですか？

OpenID Connect Coreでは、IDトークンはJWTとして定義されています。

Q6. OpenID Connectを使うには何を指定しますか？

Authorization RequestのScopeに、

openid

を含めることが基本条件です。

openidが含まれなければ、有効なOAuth 2.0リクエストであってもOpenID Connectリクエストではありません。

Q7. 「Googleでログイン」はOpenID Connectですか？

Googleは、Webサイト向けのGoogleでログインについて、OpenID Connectを基盤とするGoogle Identity Servicesを提供しています。

認証結果としてOpenID Connect形式のIDトークンが利用されます。

Q8. OAuthのScopeとOpenID ConnectのScopeは同じですか？

OpenID ConnectはOAuthのScopeの仕組みを利用しています。

OpenID Connectではopenidのほか、profile、email、address、phoneなど、ユーザー情報を要求するScopeも定義されています。

Q9. OAuth 2.1はもう正式なRFCですか？

2026年9月時点では、OAuth 2.1はIETFで作業中のInternet-Draftであり、正式なRFCとして公開された状態ではありません。

現在のOAuth 2.0実装では、RFC 9700のSecurity Best Current Practiceなど、最新の正式文書を確認することが重要です。

Q10. 迷ったときの簡単な見分け方は？

「アプリに何かへのアクセスを許したい？」 → OAuth

「外部アカウントで本人確認・ログインしたい？」 → OpenID Connect

と考えてください。

まとめ

「OAuth」と「OpenID Connect」は、一緒に使われることが多いため混同されやすい言葉ですが、主な目的は異なります。

OAuth 2.0	OpenID Connect
認可	認証
アプリに何を許可するか	利用者が誰なのか確認する
Access Tokenが中心	ID Tokenを追加
API・リソースへの限定アクセス	ログイン・ID連携
RFC 6749など	OpenID Connect Core 1.0

最も簡単な覚え方は、

OAuth＝「権限を与える」

OpenID Connect＝「本人を確認する」

です。

OAuthでは、利用者のパスワードを第三者アプリへ渡さずに、

「写真だけ読んでよい」

「予定表だけ利用してよい」

といった限定的なアクセスを認可できます。

そこで利用される代表的な資格情報がアクセストークンです。

一方、OpenID ConnectはOAuth 2.0を基盤として、

「認証されたユーザーは誰なのか」

をクライアントが確認できるようにします。

その中心となるのがIDトークンです。

したがって、

Access Token＝リソースへのアクセス

ID Token＝ユーザー認証の結果

と区別することも非常に重要です。

また、OpenID ConnectはOAuth 2.0と競合するものではなく、OAuth 2.0の仕組みを利用して認証機能を実現します。

現実の「外部アカウントでログイン」では、

OpenID Connectでユーザーを認証し、OAuthで必要なAPIアクセスを認可する

というように、両方を同時に利用するケースがあります。

OAuth・OpenID Connectを理解するときは、

「認証か、認可か」

「IDトークンか、アクセストークンか」

という2つの視点で整理すると、違いを理解しやすくなります。

参考リンク・出典

• IETF / RFC Editor「RFC 6749: The OAuth 2.0 Authorization Framework」
  ― OAuth 2.0を、第三者アプリケーションへHTTPサービスに対する限定的アクセスを与える認可フレームワークとして規定
• OpenID Foundation「OpenID Connect Core 1.0 incorporating errata set 2」
  ― OpenID ConnectをOAuth 2.0上のIdentity Layerとして定義し、認証、ID Token、Claims、UserInfo Endpoint等を規定
• OpenIDファウンデーション・ジャパン「公開資料」
  ― OpenID Connect Core 1.0などOpenID関連技術仕様の日本語資料・日本語訳を公開
• IETF / RFC Editor「RFC 9700: Best Current Practice for OAuth 2.0 Security」
  ― OAuth 2.0の最新セキュリティBCP。PKCE、リダイレクトURI、トークン保護等の推奨事項を更新し、Implicit GrantやResource Owner Password Credentials Grantなどを非推奨・廃止対象として整理
• Google for Developers「OpenID Connect」
  ― GoogleでログインがOpenID Connectを基盤とし、ID Tokenによるユーザー認証、Access TokenによるAPIアクセス等を利用することを説明
• IETF Datatracker「The OAuth 2.1 Authorization Framework」
  ― OAuth 2.1の標準化作業状況を掲載。2026年9月時点ではIETFのInternet-Draftとして作業中

※本記事では一般ユーザー・Web担当者向けに、「OAuth＝認可」「OpenID Connect＝OAuth 2.0を基盤とした認証」と整理しています。実際の実装では認証・同意・認可・トークン発行が一連の画面遷移で行われることがあり、利用者からは境界が見えにくい場合があります。

※アクセストークンとIDトークンは役割が異なります。APIへIDトークンを送信したり、アクセストークンをユーザー認証の証明として安易に扱ったりしないことが重要です。

※OAuth 2.0およびOpenID Connectを実装する場合は、古いサンプルコードだけで判断せず、RFC 9700など現在のセキュリティBCPや利用する認可サーバーの最新資料を確認してください。

※OAuth 2.1は2026年9月時点では正式なRFCではありません。Internet-Draftは変更・置換される可能性があるため、実装の根拠には確定済みのRFC・BCPと利用サービスの最新仕様を併せて確認してください。

※本記事はOAuth・OpenID Connectの基本概念を理解するための一般的な解説であり、個別システムの認証・認可設計やセキュリティを保証するものではありません。