Keycloakとは?初心者向けに認証・認可の基本からわかりやすく解説

ITインフラ
この記事は約19分で読めます。

この記事の最終更新日: 2026年5月23日

Webアプリや業務システムを開発していると、必ず出てくるのが ログイン機能 です。

最初は、メールアドレスとパスワードでログインできれば十分に見えるかもしれません。

しかし、実際のシステムでは次のような要件が出てきます。

ユーザー登録をしたい
ログイン・ログアウトを実装したい
パスワードリセットをしたい
Googleログインを使いたい
複数アプリでシングルサインオンしたい
管理者だけが見られる画面を作りたい
APIをアクセストークンで保護したい
ユーザーごとに権限を分けたい

これらをすべて自前で作るのは大変です。

そこで使われるのが Keycloak です。

Keycloakは、WebアプリケーションやAPIにログイン、ユーザー管理、SSO、外部IDプロバイダー連携などを追加するためのオープンソースの認証・認可基盤です。Keycloak公式サイトでも、アプリケーションへの認証追加、サービスの保護、既存のOpenID ConnectやSAML 2.0のIdentity Providerとの連携、ソーシャルログインなどができると説明されています。(Keycloak)

この記事では、Keycloakとは何か、認証・認可とは何か、Keycloakを使うと何が便利なのかを初心者向けに解説します。


Keycloakとは?

Keycloak は、アプリケーションの認証・認可をまとめて管理するためのOSSです。

簡単に言うと、Keycloakは次のような役割を持ちます。

ログイン画面を提供する
ユーザーを管理する
パスワードを管理する
ログイン状態を管理する
アクセストークンを発行する
アプリケーションごとの権限を管理する
SSOを実現する
GoogleやGitHubなどの外部ログインと連携する

KeycloakはOpenID Connect、OAuth 2.0、SAMLに対応したサーバーとして、対応する技術スタックであればアプリケーションやサービスを保護できると公式ガイドで説明されています。(Keycloak)

つまりKeycloakは、単なる「ログイン画面を作るツール」ではありません。

ログイン、ユーザー管理、トークン発行、権限管理、SSO、外部ID連携をまとめて扱う認証・認可基盤です。


そもそも認証とは?

Keycloakを理解するには、まず 認証認可 の違いを押さえる必要があります。

認証 とは、ユーザーが「誰なのか」を確認することです。

たとえば、次のような処理が認証です。

メールアドレスとパスワードでログインする
Googleアカウントでログインする
二要素認証で本人確認する
社員アカウントでログインする

要するに、認証は 本人確認 です。

アプリ側から見ると、

この人は本当に田中さんなのか?
この人は登録済みユーザーなのか?
このログイン情報は正しいのか?

を確認する処理です。

Keycloakは、この認証処理をアプリケーションの外側に切り出して管理できます。公式ドキュメントでも、Keycloakはアプリケーションやサービスがユーザーを認証・認可するために利用できるOpenID Connectのエンドポイントを公開すると説明されています。(Keycloak)


そもそも認可とは?

認可 とは、ログインしたユーザーに「何を許可するか」を決めることです。

たとえば、次のような処理が認可です。

一般ユーザーは管理画面を見られない
管理者だけがユーザー一覧を見られる
有料会員だけが特定機能を使える
営業部のユーザーだけが営業データを見られる
APIアクセスには特定の権限が必要

認証が「あなたは誰ですか?」を確認する処理なら、認可は「あなたは何をしてよいですか?」を判断する処理です。

認証:誰かを確認する
認可:何をしてよいかを決める

この2つは似ていますが、役割は違います。

よくある例で言うと、会社の入館証に近いです。

入館証で本人確認する → 認証
入れる部屋が決まっている → 認可

Keycloakでは、RoleやGroupなどを使って、ユーザーに権限を付与できます。KeycloakのRealmは、ユーザー、アプリケーション、ロール、グループなどを管理する空間として説明されています。(Keycloak)


Keycloakを使わない場合の問題

小さなアプリであれば、自前でログイン機能を作ることもできます。

たとえば、Laravel、Rails、Django、Spring Bootなどには認証機能を作る仕組みがあります。

しかし、システムが大きくなると、自前認証には次のような問題が出てきます。

アプリごとにログイン機能を作る必要がある
パスワード管理をアプリごとに実装する必要がある
ユーザー管理が分散する
SSOを作るのが大変
外部ログイン連携が増えるほど複雑になる
認証仕様の理解が必要になる
セキュリティ対応の責任が重くなる

たとえば、社内に複数のWebアプリがある場合、それぞれのアプリにログイン機能があると、ユーザーはアプリごとにログインしなければいけません。

また、ユーザー情報や権限情報もアプリごとにバラバラになりがちです。

Keycloakを使うと、認証・ユーザー管理をKeycloak側に集約できます。

アプリA
アプリB
アプリC
   ↓
Keycloakでログイン・ユーザー管理を共通化

このように、複数アプリの認証をまとめられるのがKeycloakの大きなメリットです。


Keycloakでできること

Keycloakでできることを整理すると、主に次のようになります。

ログイン機能
ユーザー管理
ロール管理
グループ管理
SSO
OpenID Connect対応
OAuth 2.0対応
SAML対応
外部IdP連携
ソーシャルログイン
トークン発行
アカウント管理
管理コンソール

Keycloak公式サイトでは、アプリケーションへの認証追加、サービス保護、ソーシャルログイン、既存のOpenID ConnectやSAML 2.0 Identity Providerとの連携が紹介されています。(Keycloak)

また、Keycloakのアプリケーション保護ガイドでは、Keycloakでアプリケーションやサービスを保護する基本手順として、RealmにClientを登録し、アプリケーション側でOpenID ConnectまたはSAMLを有効にする流れが説明されています。(Keycloak)

初心者は、まず次のように理解するとよいです。

Keycloakは、ログインと権限管理をアプリの外に切り出すための仕組み


Keycloakの基本用語

Keycloakを使い始めると、いくつか独特の用語が出てきます。

特に重要なのは次の用語です。

Realm
Client
User
Group
Role
Token
Identity Provider

このあたりを理解しないと、管理画面で何を設定しているのかわかりにくくなります。

順番に見ていきます。


Realmとは?

Realm は、Keycloakにおける管理単位です。

公式ドキュメントでは、Realmはユーザー、アプリケーション、ロール、グループなどを管理する空間であり、ユーザーはRealmに所属してログインすると説明されています。1つのKeycloak環境に複数のRealmを作成できます。(Keycloak)

初心者向けに言うと、Realmは 認証管理の箱 です。

たとえば、次のように分けられます。

社内システム用Realm
顧客向けサービス用Realm
開発環境用Realm
検証環境用Realm
本番環境用Realm

Realmごとに、ユーザー、Client、Role、Groupなどを分けて管理できます。

Realm A
  - User
  - Client
  - Role
  - Group

Realm B
  - User
  - Client
  - Role
  - Group

別のRealmにいるユーザーやClientは基本的に別管理になります。

そのため、環境やサービスを分けたい場合にRealmを使います。


Clientとは?

Client は、Keycloakを利用するアプリケーションのことです。

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

Reactのフロントエンドアプリ
LaravelのWebアプリ
FastAPIのAPIサーバー
社内管理画面
スマホアプリ

Keycloakのアプリケーション保護ガイドでは、アプリケーションやサービスを保護する基本手順として、まずRealmにClientを登録することが説明されています。(Keycloak)

つまり、アプリをKeycloakでログインさせたい場合、Keycloak側に「このアプリがKeycloakを使います」と登録する必要があります。

それがClientです。

Keycloak
  └── Realm
       └── Client: my-web-app
       └── Client: my-api

Clientには、ログイン後のリダイレクトURL、認証方式、許可するフローなどを設定します。

初心者がよくつまずくのは、Clientの設定です。

特に次の項目は間違えやすいです。

Client ID
Valid Redirect URIs
Web Origins
Client authentication
Access type

ログイン後にリダイレクトできない場合や、CORSエラーが出る場合は、Client設定を見直すことが多いです。


Userとは?

User は、Keycloakでログインする利用者です。

たとえば、次のようなユーザーです。

一般ユーザー
管理者
社内社員
顧客
テストユーザー

Keycloakでは、ユーザーを管理画面から作成できます。

ユーザーには、次のような情報を持たせることができます。

ユーザー名
メールアドレス
氏名
パスワード
ロール
グループ
属性

アプリ側でユーザー情報をすべて管理するのではなく、Keycloak側でユーザーを管理できます。

これにより、複数アプリで同じユーザー情報を使いやすくなります。


Roleとは?

Role は、ユーザーに与える権限や役割です。

たとえば、次のようなRoleを作れます。

admin
user
manager
viewer
editor

Roleは、認可を考えるうえで重要です。

たとえば、アプリ側で次のように判断できます。

adminロールを持つユーザーだけ管理画面を表示する
editorロールを持つユーザーだけ記事編集を許可する
viewerロールは閲覧のみ許可する

KeycloakにはRealm RoleとClient Roleがあります。

ざっくり言うと、次のような違いです。

Realm Role:Realm全体で使うロール
Client Role:特定のアプリケーション向けのロール

初心者のうちは、まず「Roleはユーザーの権限を表すもの」と理解すれば十分です。


Groupとは?

Group は、ユーザーをまとめるための仕組みです。

たとえば、次のようなGroupを作れます。

管理部
営業部
開発部
有料会員
社内ユーザー
外部パートナー

GroupにRoleを割り当てることで、そのGroupに所属するユーザーへまとめて権限を付与できます。

Group: 管理者グループ
  └── Role: admin

Group: 一般ユーザーグループ
  └── Role: user

ユーザーごとにRoleを直接付けるより、Groupで管理した方が運用しやすい場合があります。

たとえば、社員が異動したときにGroupを変更するだけで権限を調整できます。


Tokenとは?

Keycloakを使うと、ログイン後に Token が発行されます。

代表的なのは次の3つです。

ID Token
Access Token
Refresh Token

ざっくり言うと、次のような役割です。

ID Token:ログインしたユーザーの情報を表す
Access Token:APIアクセス時に使う
Refresh Token:Access Tokenを再発行するために使う

KeycloakはOpenID Connect Providerとして、アプリケーションやサービスがユーザーの認証・認可に使うエンドポイントを提供します。(Keycloak)

APIを保護する場合、よく使われるのがAccess Tokenです。

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

Authorization: Bearer <access_token>

API側は、このAccess Tokenが正しいか、必要なRoleを持っているかを確認します。


OpenID Connectとは?

Keycloakを理解するうえで、OpenID Connect という言葉がよく出てきます。

OpenID Connect、略してOIDCは、ログイン認証のためによく使われるプロトコルです。

KeycloakはOpenID Connect Providerとして、アプリケーションやサービスがユーザーを認証・認可するために使うエンドポイント群を提供します。(Keycloak)

初心者向けに言うと、OpenID Connectは次のような仕組みです。

アプリがKeycloakにログインを依頼する
ユーザーがKeycloakでログインする
Keycloakがアプリにトークンを返す
アプリはトークンを見てログイン済みと判断する

自前でパスワードを受け取って認証するのではなく、Keycloakのような認証基盤にログイン処理を任せます。


OAuth 2.0とは?

OAuth 2.0は、主に「アクセス許可」を扱うための仕組みです。

たとえば、APIを呼ぶためのAccess Tokenを発行し、そのトークンを使ってリソースにアクセスします。

KeycloakはOAuth 2.0、OpenID Connect、SAMLに対応したサーバーとして、対応するアプリケーションやサービスを保護できます。(Keycloak)

初心者は、まず次のように整理するとよいです。

OpenID Connect:ログイン認証に関係する
OAuth 2.0:APIアクセス許可に関係する

実際にはOpenID ConnectはOAuth 2.0の上に作られているため、両方の概念が重なります。

Keycloakを使う場合、ログイン画面、トークン発行、API認証などがまとめて登場するため、最初は混乱しやすいです。


SSOとは?

SSO は、Single Sign-Onの略です。

一度ログインすれば、複数のアプリケーションに再ログインせずアクセスできる仕組みです。

たとえば、社内に次のようなアプリがあるとします。

勤怠システム
経費精算システム
社内ポータル
顧客管理システム

それぞれ別々にログインするのは面倒です。

Keycloakを使ってSSOを構成すると、一度Keycloakでログインすれば、複数アプリでログイン状態を共有しやすくなります。

ユーザー
  ↓ ログイン
Keycloak
  ↓
社内アプリA
社内アプリB
社内アプリC

Keycloakの公式サイトでも、アプリケーションへの認証追加やSSO、外部Identity Providerとの連携ができることが紹介されています。(Keycloak)


外部IdP連携とは?

Keycloakでは、Google、GitHub、Azure ADなどの外部Identity Providerと連携できます。

これを Identity Brokering と呼びます。

公式サイトでは、Keycloakは既存のOpenID ConnectやSAML 2.0 Identity Providerでユーザーを認証でき、管理コンソールからIdentity Providerを設定できると説明されています。(Keycloak)

たとえば、次のような構成ができます。

ユーザー
  ↓
Keycloak
  ↓
Googleログイン
GitHubログイン
Azure ADログイン

アプリ側はKeycloakとだけ連携し、Keycloakが外部ログインとの橋渡しをします。

これにより、アプリごとにGoogleログイン、GitHubログイン、Azure ADログインを個別実装しなくてよくなります。


Keycloakを使うメリット

1. ログイン機能を共通化できる

複数のアプリでログイン機能を自前実装すると、管理が大変になります。

Keycloakを使えば、ログイン処理をKeycloak側に集約できます。

アプリAのログイン
アプリBのログイン
アプリCのログイン
  ↓
Keycloakに集約

これにより、ユーザー管理や認証フローを共通化しやすくなります。


2. SSOを実現しやすい

Keycloakを使うと、複数アプリ間でSSOを実現しやすくなります。

ユーザーは一度ログインすれば、対応する複数アプリへアクセスしやすくなります。

社内システムや業務システムでは特に便利です。


3. 標準プロトコルに対応している

KeycloakはOpenID Connect、OAuth 2.0、SAMLに対応しています。公式ガイドでも、Keycloakはこれらに準拠したサーバーとして、対応するアプリケーションやサービスを保護できると説明されています。(Keycloak)

標準プロトコルに対応しているため、さまざまなアプリケーションやフレームワークと連携しやすいです。


4. 外部ログインと連携しやすい

Keycloakは、Googleなどのソーシャルログインや既存のIdentity Providerとの連携を管理コンソールから設定できます。(Keycloak)

これにより、アプリ側で外部ログインを個別に実装する負担を減らせます。


5. ユーザー・ロール・グループを管理できる

Keycloakでは、Realmの中でユーザー、アプリケーション、ロール、グループを管理できます。(Keycloak)

ユーザーごと、グループごと、アプリごとに権限を整理しやすくなります。


Keycloakのデメリット・注意点

Keycloakは便利ですが、導入すればすべてが簡単になるわけではありません。

注意点もあります。

1. 概念が多い

Keycloakには、Realm、Client、Role、Group、Scope、Token、Identity Providerなど、多くの概念があります。

初心者は、最初に管理画面を開いたときに何を設定すればよいかわからなくなりがちです。

まずは次の4つから理解するのがおすすめです。

Realm
Client
User
Role


2. 設定ミスでログインできなくなる

Keycloakでは、ClientのRedirect URIやWeb Originsなどを正しく設定する必要があります。

ここを間違えると、次のような問題が起きます。

ログイン後にリダイレクトできない
CORSエラーになる
invalid redirect_uriが出る
トークンが取得できない

初心者は、まずシンプルなローカル環境で動かしてから、本番構成に進むとよいです。


3. 本番運用には設計が必要

Keycloakを本番で使う場合は、単にDockerで起動するだけでは不十分です。

次のような点を考える必要があります。

データベース
バックアップ
冗長化
HTTPS
リバースプロキシ
管理者アカウント
監査ログ
バージョンアップ
メール設定
セキュリティ設定

Keycloakは認証基盤なので、止まるとログインできなくなる可能性があります。

そのため、本番運用ではかなり慎重に設計する必要があります。


Keycloakの基本的な使い方

Keycloakでアプリを保護する基本的な流れは、次のようになります。

Keycloakを起動する
Realmを作る
Clientを作る
Userを作る
Roleを作る
アプリ側でOIDC設定をする
ログインしてトークンを取得する
API側でトークンを検証する

公式ガイドでも、Keycloakでアプリケーションやサービスを保護する基本手順として、RealmにClientを登録し、アプリケーション側でOpenID ConnectまたはSAMLを有効にする流れが説明されています。(Keycloak)

初心者は、まず1つのWebアプリをKeycloakログインに対応させるところから始めるとよいです。


Keycloakとアプリの関係

Keycloakを使う場合、アプリはログイン処理の一部をKeycloakに任せます。

ざっくりした流れは次の通りです。

ユーザーがアプリにアクセスする
↓
アプリがKeycloakのログイン画面へリダイレクトする
↓
ユーザーがKeycloakでログインする
↓
Keycloakがトークンを発行する
↓
アプリがトークンを受け取る
↓
アプリはログイン済みとして扱う

APIを保護する場合は、Access Tokenを使います。

フロントエンド
  ↓ Authorization: Bearer access_token
APIサーバー
  ↓
トークンを検証
  ↓
アクセス許可を判断

このように、Keycloakはログイン画面だけでなく、トークン発行とAPI保護にも関わります。


Keycloakはどんな場面で使うべき?

Keycloakは、次のような場面で特に向いています。

複数アプリで共通ログインを使いたい
社内システムでSSOを導入したい
ユーザー管理を一元化したい
APIをトークンで保護したい
ロールベースの権限管理をしたい
外部IdPと連携したい
自前認証を減らしたい

逆に、次のような場合は最初からKeycloakを使わなくてもよいかもしれません。

非常に小さな個人アプリ
ログイン要件が単純
ユーザー数が少ない
SSOが不要
自前フレームワークの認証機能で十分

Keycloakは便利ですが、学習コストと運用コストがあります。

小さなアプリであれば、Laravel Breeze、Rails Devise、Firebase Authentication、Supabase Authなどの方が手軽な場合もあります。

一方で、複数アプリ、業務システム、社内SSO、API認証が絡む場合はKeycloakが有力な選択肢になります。


初心者が最初に学ぶべき順番

Keycloak初心者は、次の順番で学ぶと理解しやすいです。

1. 認証と認可の違いを理解する
2. OpenID Connectのざっくりした流れを理解する
3. KeycloakをDockerで起動する
4. Realmを作る
5. Clientを作る
6. Userを作る
7. ブラウザでログインを試す
8. Access Tokenを確認する
9. API側でトークン検証する
10. Roleを使って権限管理する

いきなりSAML、外部IdP、細かいScope、Protocol Mapperまで学ぼうとすると難しくなります。

まずは、Realm、Client、User、Roleを使ってログインできる状態を作るのがおすすめです。


よくあるつまずきポイント

1. RealmとClientの違いがわからない

Realmは認証管理の箱です。

ClientはKeycloakを利用するアプリです。

Realm:ユーザー・アプリ・ロールなどを管理する空間
Client:Keycloakで認証したいアプリ

ここを混同すると、管理画面で迷いやすくなります。


2. Redirect URIの設定ミス

ログイン後にアプリへ戻るためには、ClientのRedirect URI設定が重要です。

ここが間違っていると、ログイン後にエラーになります。

開発環境なら、たとえば次のようなURLを許可することがあります。

ただし、本番環境ではワイルドカードを雑に使うのは避けるべきです。


3. Access TokenとID Tokenを混同する

ID Tokenはユーザー認証情報に関係します。

Access TokenはAPIアクセスに使います。

ID Token:ログインしたユーザー情報
Access Token:APIアクセス用

API保護では、基本的にAccess Tokenを検証します。


4. Roleがトークンに入っていない

KeycloakでRoleを作っても、アプリ側で期待した形でトークンに含まれないことがあります。

その場合は、Client ScopeやMapperの設定を確認する必要があります。

初心者は、まずKeycloakの管理画面やトークン内容を確認し、どのClaimにRoleが入っているかを見るとよいです。


5. 401と403の違いがわからない

Keycloak連携では、401と403の違いも重要です。

401 Unauthorized:認証されていない
403 Forbidden:認証はされているが権限がない

ログインしていないなら401。

ログインしているが必要なRoleがないなら403。

この違いを理解すると、API認証・認可のデバッグがしやすくなります。


Keycloakを学ぶメリット

Keycloakを学ぶと、単に1つのツールが使えるだけではありません。

認証・認可の基礎理解が深まります。

OpenID Connect
OAuth 2.0
SAML
JWT
Access Token
Refresh Token
SSO
Role Based Access Control
Identity Provider

これらは、Webアプリ開発やAPI開発で非常に重要な概念です。

Keycloakを触ることで、実際の管理画面やトークンを見ながら認証・認可を学べるのは大きなメリットです。


まとめ

Keycloakは、アプリケーションの認証・認可を管理するためのオープンソースの認証基盤です。

ログイン、ユーザー管理、SSO、外部IdP連携、OpenID Connect、OAuth 2.0、SAML、トークン発行、ロール管理などを扱えます。KeycloakはOpenID Connect、OAuth 2.0、SAMLに対応しており、対応するアプリケーションやサービスを保護できると公式ドキュメントで説明されています。(Keycloak)

初心者がまず理解すべきポイントは次の通りです。

認証:ユーザーが誰かを確認する
認可:ユーザーが何をしてよいかを決める
Realm:認証管理の箱
Client:Keycloakを使うアプリ
User:ログインする利用者
Role:権限や役割
Token:ログインやAPIアクセスに使う情報

Keycloakは、複数アプリのログインを共通化したい場合、SSOを導入したい場合、APIをトークンで保護したい場合、ユーザーや権限を一元管理したい場合に有力な選択肢です。

最初は難しく見えますが、Realm、Client、User、Roleの4つから学べば、Keycloakの全体像はかなり理解しやすくなります。

コメント

タイトルとURLをコピーしました