KeycloakとOAuth 2.0・OpenID Connectの関係を初心者向けに解説

この記事の最終更新日: 2026年6月20日

Keycloakを使い始めると、必ず出てくるのが OAuth 2.0 と OpenID Connect です。

管理画面にも、Client、Redirect URI、Access Token、ID Token、Client Secret、Scopeなど、認証・認可まわりの用語がたくさん出てきます。

最初は、こう感じる人も多いと思います。

KeycloakとOAuth 2.0は何が違うの？
OpenID Connectって何？
OAuth 2.0はログインの仕組みじゃないの？
Access TokenとID Tokenはどう違うの？
Keycloakは結局どの役割なの？

この記事では、KeycloakとOAuth 2.0、OpenID Connectの関係を、初心者向けにわかりやすく整理します。

まず結論：KeycloakはOAuth 2.0・OpenID Connectを扱える認証基盤
OAuth 2.0とは？
OpenID Connectとは？
OAuth 2.0とOpenID Connectの違い
Keycloakはどの役割なのか？
登場人物を整理する
Keycloakを使ったログインの流れ
Access Tokenとは？
ID Tokenとは？
Refresh Tokenとは？
KeycloakのClientは何を表すのか？
Redirect URIとは？
Scopeとは？
Keycloakのエンドポイント
Authorization Code Flowとは？
PKCEとは？
OAuth 2.0だけでログインしてはいけないのか？
KeycloakでAPIを保護する流れ
401と403の違い
よくある誤解
誤解1：KeycloakとOAuth 2.0は同じもの
誤解2：OAuth 2.0はログインの仕組み
誤解3：Access Tokenを見ればログインユーザー情報は十分
誤解4：Tokenを保存すれば安全
Keycloakを学ぶ順番
Keycloak・OAuth 2.0・OpenID Connectの関係まとめ
まとめ

まず結論：KeycloakはOAuth 2.0・OpenID Connectを扱える認証基盤

Keycloakは、OAuth 2.0、OpenID Connect、SAMLなどに対応した認証・認可基盤です。Keycloak公式ドキュメントでも、KeycloakはOAuth2、OpenID Connect、SAMLに準拠したサーバーとして、対応するアプリケーションやサービスを保護できると説明されています。(Keycloak)

ざっくり言うと、関係はこうです。

OAuth 2.0
→ アクセス許可のための仕組み

OpenID Connect
→ OAuth 2.0の上に作られたログイン認証の仕組み

Keycloak
→ OAuth 2.0 / OpenID Connect を実装している認証・認可サーバー

つまり、OAuth 2.0やOpenID Connectは「ルール・仕様」です。

Keycloakは、その仕様を実際に使えるようにした「製品・サーバー」です。

OAuth 2.0とは？

OAuth 2.0 は、認可のための仕組みです。

認可とは、簡単に言うと 何をしてよいかを許可すること です。

たとえば、次のような場面で使われます。

このアプリにGoogleカレンダーの予定を読む権限を与える
このアプリにGitHubリポジトリを見る権限を与える
このユーザーにAPIアクセスを許可する
このClientに特定のResource Serverへのアクセスを許可する

RFC 6749では、OAuth 2.0は、第三者アプリケーションがHTTPサービスへ限定的なアクセスを取得できるようにする認可フレームワークだと説明されています。(IETF Datatracker)

ここで重要なのは、OAuth 2.0は本来、ログインそのものを定義する仕様ではない という点です。

OAuth 2.0の中心は、次の問いです。

このアプリは、どのリソースに、どの範囲でアクセスしてよいか？

つまり、OAuth 2.0は「あなたは誰ですか？」よりも、「このアプリに何を許可しますか？」に近い仕組みです。

OpenID Connectとは？

OpenID Connect、略して OIDC は、OAuth 2.0の上に作られた認証の仕組みです。

認証とは、簡単に言うと ユーザーが誰なのかを確認すること です。

OpenID Connect Core仕様では、OpenID Connect 1.0はOAuth 2.0プロトコルの上にあるシンプルなIdentity Layerであり、ClientがEnd-Userの本人性を検証し、基本的なプロフィール情報を取得できるようにするものだと説明されています。(OpenID財団)

つまり、OpenID Connectは次の問いに答えるための仕組みです。

このユーザーは誰なのか？
本当にログイン済みなのか？
ログインしたユーザーの識別子は何か？

OAuth 2.0だけでは、「ログインしたユーザーが誰か」を標準的に扱うには不十分です。

そこで、OAuth 2.0にログイン認証の仕組みを追加したものがOpenID Connectです。

OAuth 2.0とOpenID Connectの違い

初心者向けに、かなりシンプルに整理するとこうです。

項目	OAuth 2.0	OpenID Connect
主な目的	認可	認証
中心の問い	何を許可するか	誰がログインしたか
主に使うトークン	Access Token	ID Token
用途	APIアクセス許可	ログイン認証
関係	土台	OAuth 2.0の上にある拡張

もう少し実務寄りに言うと、次のようになります。

OAuth 2.0：
APIにアクセスするためのAccess Tokenを扱う

OpenID Connect：
ログインしたユーザーを表すID Tokenを扱う

ただし、実際のWebアプリではOAuth 2.0とOpenID Connectをセットで使うことが多いです。

たとえば、Keycloakでログインすると、ID Token、Access Token、Refresh Tokenなどが発行されます。

Keycloakはどの役割なのか？

Keycloakは、OAuth 2.0やOpenID Connectの世界では、主に Authorization Server や OpenID Provider の役割を持ちます。

Keycloak公式ドキュメントでは、KeycloakはOpenID Connect Providerとして、アプリケーションやサービスがユーザーを認証・認可するために使えるエンドポイント群を公開すると説明されています。(Keycloak)

簡単に図にすると、こうです。

ユーザー
  ↓ ログイン
Keycloak
  ↓ トークン発行
Webアプリ / API

Keycloakの役割は、主に次の通りです。

ログイン画面を提供する
ユーザーを認証する
認可コードを発行する
Access Tokenを発行する
ID Tokenを発行する
Refresh Tokenを発行する
公開鍵情報を提供する
Token検証に必要なエンドポイントを提供する

つまりKeycloakは、OAuth 2.0 / OpenID Connectの仕様に沿って、ログインやトークン発行を担当するサーバーです。

登場人物を整理する

OAuth 2.0やOpenID Connectでは、いくつかの登場人物があります。

初心者がまず押さえるべきなのは、次の4つです。

用語	意味
Resource Owner	ユーザー
Client	アプリケーション
Authorization Server	認可サーバー。Keycloakが担当
Resource Server	APIサーバー

Keycloakを使ったWebアプリでは、たとえば次のような関係になります。

Resource Owner:
ユーザー

Client:
Reactアプリ、Laravelアプリ、管理画面など

Authorization Server:
Keycloak

Resource Server:
バックエンドAPI

OAuth 2.0の仕様でも、Client、Resource Owner、Authorization Server、Resource Serverといった役割が定義されています。(IETF Datatracker)

Keycloakを使ったログインの流れ

KeycloakとOpenID Connectを使ったWebログインの流れは、ざっくり次のようになります。

ユーザーがWebアプリにアクセスする
↓
WebアプリがKeycloakへリダイレクトする
↓
ユーザーがKeycloakのログイン画面でログインする
↓
KeycloakがWebアプリへ認可コードを返す
↓
Webアプリが認可コードを使ってトークンを取得する
↓
WebアプリはID Tokenでユーザーを確認する
↓
API呼び出しにはAccess Tokenを使う

この流れは、OpenID Connectでよく使われるAuthorization Code Flowの考え方です。

現在のWebアプリやSPAでは、Authorization Code FlowにPKCEを組み合わせる構成がよく使われます。

Access Tokenとは？

Access Token は、APIへアクセスするためのトークンです。

たとえば、フロントエンドがバックエンドAPIを呼ぶときに、次のように付けます。

Authorization: Bearer &lt;access_token>

APIサーバーは、このAccess Tokenを見て、次のようなことを判断します。

このトークンは正しいか
有効期限は切れていないか
どのユーザー・Clientに発行されたものか
どのRoleやScopeを持っているか
このAPIを呼ぶ権限があるか

Access Tokenは、主に認可のために使います。

つまり、「このリクエストは許可してよいか？」を判断する材料です。

ID Tokenとは？

ID Token は、ログインしたユーザーの本人性を表すトークンです。

OpenID Connectでは、ID Tokenが重要です。

ID Tokenには、たとえば次のような情報が含まれます。

ユーザーID
ユーザー名
メールアドレス
発行者
発行時刻
有効期限
認証されたことを示す情報

ID Tokenの主な目的は、Clientが「このユーザーはKeycloakで認証された」と確認することです。

OpenID Connect仕様でも、OpenID ConnectはClientがEnd-Userの本人性を検証できるようにするIdentity Layerだと説明されています。(OpenID財団)

ざっくり言うと、こうです。

ID Token：
ログインしたユーザーが誰かを表す

Access Token：
APIへアクセスする権限を表す

Refresh Tokenとは？

Refresh Token は、Access Tokenを再発行するためのトークンです。

Access Tokenは通常、有効期限を短めにします。

なぜなら、Access Tokenが漏れたときの被害を抑えるためです。

しかし、有効期限が短すぎると、ユーザーは頻繁にログインし直す必要があります。

そこで使うのがRefresh Tokenです。

Access Tokenの期限が切れる
↓
Refresh Tokenを使って新しいAccess Tokenを取得する
↓
ユーザーは再ログインせずに利用を続けられる

ただし、Refresh Tokenは強力なトークンなので、扱いには注意が必要です。

特にブラウザアプリでどこに保存するかは、セキュリティ設計に大きく関わります。

KeycloakのClientは何を表すのか？

KeycloakでOAuth 2.0 / OpenID Connectを使うときに重要なのが Client です。

KeycloakにおけるClientは、Keycloakに認証・認可を依頼するアプリケーションです。

たとえば、次のようなものがClientになります。

Reactアプリ
Vueアプリ
Laravelアプリ
Spring Bootアプリ
FastAPIのAPIサーバー
管理画面
モバイルアプリ

Keycloak公式ドキュメントでは、ClientはKeycloakにユーザー認証を要求できるエンティティであり、多くの場合はKeycloakで保護したいアプリケーションやサービスだと説明されています。(Keycloak)

Keycloakでは、Clientごとに次のような設定を行います。

Client ID
Redirect URI
Web Origins
Client authentication
Client Secret
Allowed flows
Client scopes
Roles

OAuth 2.0 / OpenID Connectの流れを理解するには、このClient設定の意味を理解することが重要です。

Redirect URIとは？

Redirect URI は、Keycloakでログインしたあとに戻るURLです。

たとえば、Reactアプリが次のURLで動いているとします。


http://localhost:5173
localhost

この場合、Keycloak側のClient設定で、次のようにRedirect URIを許可します。


http://localhost:5173/*
localhost

ログイン後、Keycloakは許可されたRedirect URIにだけユーザーを戻します。

これを適切に設定しないと、invalid redirect_uri のようなエラーが出ます。

Redirect URIはセキュリティ上とても重要です。

もし任意のURLへリダイレクトできてしまうと、悪意あるサイトへユーザーを誘導できてしまうためです。

Scopeとは？

Scope は、Clientが要求する権限や情報の範囲です。

OpenID Connectでは、よく次のようなScopeを使います。

openid
profile
email

openid は、OpenID Connectを使うことを示す重要なScopeです。

profile や email は、ユーザーのプロフィール情報やメールアドレス情報を取得したいときに使います。

Keycloakでは、Client Scopeの設定によって、Tokenにどの情報を含めるかを調整できます。

たとえば、「RoleをTokenに含めたい」「メールアドレスをID Tokenに含めたい」といった場合に、Client ScopeやMapperの設定が関係します。

Keycloakのエンドポイント

Keycloakは、OpenID Connect Providerとしてさまざまなエンドポイントを提供します。

Keycloak公式ドキュメントでは、KeycloakはOpenID Connect Providerとして、アプリケーションやサービスがユーザーを認証・認可するためのエンドポイントを公開していると説明されています。(Keycloak)

代表的なものは次の通りです。

Authorization Endpoint
Token Endpoint
UserInfo Endpoint
Logout Endpoint
JWKS Endpoint
Introspection Endpoint

初心者が最初に理解すべきなのは、次の3つです。

Authorization Endpoint：
ログイン画面へリダイレクトする先

Token Endpoint：
認可コードをトークンに交換する先

JWKS Endpoint：
トークン署名検証用の公開鍵を取得する先

通常、アプリ側のライブラリがこれらのエンドポイントを自動的に使ってくれます。

しかし、トラブルシュートするときは、これらの役割を理解していると非常に役立ちます。

Authorization Code Flowとは？

Keycloakを使ったWebアプリ連携でよく使うのが、Authorization Code Flow です。

流れは次のようになります。

1. アプリがKeycloakへリダイレクトする
2. ユーザーがKeycloakでログインする
3. Keycloakが認可コードをアプリへ返す
4. アプリが認可コードをToken Endpointへ送る
5. KeycloakがTokenを返す

この方式では、ログイン後にいきなりAccess TokenをURLに載せるのではなく、一度「認可コード」を返し、それを安全にTokenへ交換します。

サーバーサイドWebアプリでは、Client Secretを使ってTokenを取得する構成がよくあります。

SPAの場合は、Client Secretを安全に持てないため、PKCEを組み合わせるのが一般的です。

PKCEとは？

PKCE は、Public Client向けにAuthorization Code Flowを安全に使うための仕組みです。

SPAやモバイルアプリは、Client Secretを安全に保持できません。

なぜなら、ブラウザのJavaScriptやモバイルアプリ内に秘密情報を入れても、解析される可能性があるからです。

そこで、PKCEを使います。

ざっくり言うと、PKCEではClient Secretの代わりに、一時的な検証用の値を使って認可コードの横取りリスクを下げます。

初心者は、まず次のように理解すれば十分です。

SPAやモバイルアプリでは、
Authorization Code Flow + PKCE を使うのが基本

OAuth 2.0だけでログインしてはいけないのか？

よくある誤解が、「OAuth 2.0でログインする」という表現です。

実務ではこの表現が使われることもありますが、厳密には注意が必要です。

OAuth 2.0は認可フレームワークであり、ユーザー認証の標準的な情報を提供するための仕様ではありません。ユーザーの本人性を標準的に扱うために、OAuth 2.0の上にOpenID Connectが作られています。(OpenID財団)

そのため、ログイン用途ではOpenID Connectを使うのが基本です。

APIアクセス許可：
OAuth 2.0

ログイン認証：
OpenID Connect

Keycloakを使ってWebログインを実装する場合、多くはOpenID Connectとして連携することになります。

KeycloakでAPIを保護する流れ

Keycloakを使ってAPIを保護する場合、基本の流れは次の通りです。

ユーザーがKeycloakでログインする
↓
フロントエンドがAccess Tokenを取得する
↓
フロントエンドがAPIへリクエストする
↓
AuthorizationヘッダーにAccess Tokenを付ける
↓
APIサーバーがTokenを検証する
↓
RoleやScopeを見てアクセス可否を判断する

APIサーバー側では、Access Tokenの署名、有効期限、発行者、Audience、Roleなどを確認します。

たとえば、APIリクエストでは次のようにTokenを送ります。

GET /api/users
Authorization: Bearer eyJ...

このとき、APIサーバーはKeycloakの公開鍵情報を使ってJWTを検証することがあります。

401と403の違い

Keycloak連携でAPIを作るときは、401と403の違いも重要です。

401 Unauthorized：
ログインしていない、またはTokenが無効

403 Forbidden：
ログインはしているが、必要な権限がない

たとえば、Tokenがない場合は401です。

Access Tokenがない
Access Tokenが期限切れ
Access Tokenの署名が不正
Issuerが違う

一方で、Tokenは正しいがRoleが足りない場合は403です。

ログイン済み
Tokenも正しい
でもadmin Roleがない

この違いを理解すると、Keycloak連携のデバッグがかなり楽になります。

よくある誤解

誤解1：KeycloakとOAuth 2.0は同じもの

KeycloakとOAuth 2.0は同じものではありません。

OAuth 2.0：
認可のための仕様

Keycloak：
OAuth 2.0やOpenID Connectを実装したサーバー

KeycloakはOAuth 2.0を使える製品・サーバーです。

誤解2：OAuth 2.0はログインの仕組み

OAuth 2.0は本来、認可のためのフレームワークです。

ログイン認証を標準的に扱うなら、OpenID Connectを使うのが基本です。

OAuth 2.0：
何を許可するか

OpenID Connect：
誰がログインしたか

誤解3：Access Tokenを見ればログインユーザー情報は十分

Access Tokenにもユーザーに関する情報が入ることはあります。

しかし、ログイン認証の結果としてユーザーの本人性を表すのはID Tokenです。

用途としては、次のように分けて考えるのが基本です。

ID Token：
Clientがログインユーザーを確認する

Access Token：
APIがアクセス許可を確認する

誤解4：Tokenを保存すれば安全

Tokenは強力な情報です。

特にAccess TokenやRefresh Tokenが漏れると、不正アクセスにつながる可能性があります。

そのため、保存場所や有効期限、Refresh Tokenの扱い、ブラウザアプリでの保管方法には注意が必要です。

SPAでLocalStorageにTokenを置く設計などは、XSSリスクとセットで慎重に考える必要があります。

Keycloakを学ぶ順番

KeycloakとOAuth 2.0・OpenID Connectを学ぶなら、次の順番がおすすめです。

1. 認証と認可の違いを理解する
2. OAuth 2.0は認可の仕組みだと理解する
3. OpenID Connectは認証の仕組みだと理解する
4. Keycloakはそれらを実装したサーバーだと理解する
5. RealmとClientを作る
6. Redirect URIを設定する
7. ログインしてID TokenとAccess Tokenを確認する
8. APIでAccess Tokenを検証する
9. RoleやScopeで認可を制御する

いきなり細かいMapper、Client Scope、SAML、Identity Brokeringまで学ぼうとすると混乱します。

まずは、Keycloakでログインし、Tokenが発行される流れを確認するのがおすすめです。

Keycloak・OAuth 2.0・OpenID Connectの関係まとめ

最後に、3つの関係を整理します。

OAuth 2.0
→ APIアクセスなどの認可のための仕組み

OpenID Connect
→ OAuth 2.0の上にある認証の仕組み

Keycloak
→ OAuth 2.0 / OpenID Connectを実装した認証・認可サーバー

もう少し実務寄りにすると、こうです。

ユーザーがログインする
→ OpenID Connect

APIにアクセスする
→ OAuth 2.0 / Access Token

ログイン画面やトークン発行を担当する
→ Keycloak

Keycloakを使うと、OpenID Connectによるログイン認証と、OAuth 2.0によるAPIアクセス制御をまとめて扱えます。

まとめ

Keycloak、OAuth 2.0、OpenID Connectは、それぞれ役割が違います。

初心者がまず押さえるべきなのは、次の3点です。

OAuth 2.0：
認可のためのフレームワーク

OpenID Connect：
OAuth 2.0の上にある認証の仕組み

Keycloak：
OAuth 2.0 / OpenID Connectを実装した認証・認可基盤

Keycloak公式ドキュメントでも、KeycloakはOpenID Connect Providerとして、ユーザーの認証・認可に使えるエンドポイントを提供すると説明されています。(Keycloak)

Webアプリ連携では、KeycloakをAuthorization Server / OpenID Providerとして使い、アプリはClientとしてKeycloakにログインを依頼します。

ログインユーザーを確認するにはID Token、APIアクセスを許可するにはAccess Tokenを使います。

この関係が理解できると、KeycloakのClient設定、Redirect URI、Scope、Role、Token検証などがかなり見えやすくなります。

daigoro

大阪のエンジニアが書いているブログ。