はじめに

Webアプリケーションや業務システムを開発する際、避けて通れないのが「認証」の仕組みです。ユーザーのログイン機能はもちろんのこと、API連携やシステム間通信、外部サービスとの認証連携など、認証が関わる場面は年々増えています。

ユーザー管理、パスワードの安全な保存、多要素認証(MFA)、そして利便性を高めるシングルサインオン(SSO)など、これらをすべて自前で実装・運用するのは、セキュリティとコストの両面で非常にハードルが高い作業といえます。さらに、近年ではユーザーが介在しないシステム間認証や、外部クラウドサービスとの認証連携を安全に実現することも求められています。

そこで活躍するのが「認証認可サーバー」という仕組みです。本記事では、オープンソースの認証基盤として広く利用されているKeycloakを例に、認証認可サーバーの基本的な役割と利用シーンを初学者向けに解説します。

そもそも「認証」と「認可」は何が違う?

Keycloakを理解する前に、まずは混同しやすい「認証」と「認可」の違いを整理しておきましょう。

簡単に言うと、

認証(Authentication):そのユーザーが「誰であるか」を確認すること
認可(Authorization):そのユーザーが「何をしてよいか」を決めること

上の図は、ECサイトを例にしてこの違いを表したものです。

左側の「認証」の図では、ユーザーがIDとパスワードを入力し、ECサイトのサーバーがその情報をもとに本人確認を行っています。ここで重要なのは、「この人は誰なのか」を確認しているだけで、まだ何ができるかは判断していないという点です。ログインが成功すると、システムはそのユーザーを識別するためのセッション情報やトークンを発行し、「このユーザーは正しい人物である」という状態になります。

一方、右側の「認可」の図では、ログイン済みのユーザーが実際にどの操作を行えるかを判断しています。例えば、商品の閲覧やカート追加、注文処理は一般ユーザーでも可能ですが、管理画面へのアクセスは管理者権限を持つユーザーのみ許可されます。このように、認証されたユーザーの持つ権限(ロール)や属性に応じて、利用できる機能を制御するのが認可の役割です。

つまり、認証は「本人確認」、認可は「権限チェック」と考えると分かりやすいでしょう。

Keycloakとは

Keycloakは、Red Hatが開発を主導しているオープンソース(OSS)の認証認可サーバーです。無料で利用できるだけでなく、エンタープライズレベルの豊富な機能を備えています。

Keycloakは、アプリケーションの代わりにログイン処理を担当する「認証の専門サーバー」として動作します。
Keycloakの主な機能は以下の通りです。

・シングルサインオン(SSO):一度のログインで複数のアプリへアクセス可能
・多要素認証(MFA):ワンタイムパスワードなどによるセキュリティ強化
・標準プロトコル対応:OpenID Connect、OAuth2.0、SAML2.0に対応
・ユーザー管理:ユーザー情報やロール管理
・トークン発行:JWTなどのアクセストークン発行

一言で言えば、認証周りの面倒な処理を丸ごと引き受けてくれる基盤です。

押さえておきたい基本用語

Keycloakを操作する上で、以下の4つの用語を覚えておくと理解がスムーズになります。

Realm(レルム)
ユーザー、クライアント、ロール、グループなどの情報を管理するための設定単位です。

Client(クライアント)
認証・認可の対象となるアプリケーションやサービスを識別・設定する構成単位です。クライアントの設定により、KeycloakはアクセストークンやIDトークン、SAMLアサーションを発行し、認証結果を連携することが可能になります。

Client Scope(クライアントスコープ)
トークンに含めるユーザー情報(メールアドレスや権限など)を定義する設定単位です。

User(ユーザー)
ログインする利用者の情報を管理します。ユーザー名、パスワード、メールアドレスなどを保持します。

利用シーン別:代表的な認証パターン

Keycloakが対応している代表的な認証パターンを2つ紹介します。

パターン1:Client Credentials Grant(システム間認証)

ユーザー(人間)が介在せず、要求元業務システムが要求先業務システムのAPIを呼び出すような「システム間認証」で利用されるOAuth 2.0のフローです。バッチ処理やバックエンドサービス同士の連携などでよく利用されます。

① アクセストークン要求

要求元業務システム(クライアント)は、自身の Client IDClient Secret をKeycloakのトークンエンドポイントへ送信し、アクセストークンの発行を要求します。

② アクセストークン返却

Keycloakは送信された認証情報が正しいことを確認し、アクセス権限を証明するJWT形式のアクセストークンを発行して返却します。

③ リソース要求

要求元業務システムは取得したアクセストークンをHTTPヘッダー(Authorization: Bearer トークン)に付与し、宛先となる要求先業務システム(リソースサーバー)へリクエストを送信します。

④ トークンインストロスペクション

API側は受け取ったトークンが有効であるかを確認します。必要に応じてKeycloakへ問い合わせる、もしくは公開鍵を用いてトークンを検証します。

⑤ リソース返却

トークンの検証および認可判断が正常に完了した場合、APIは要求されたデータや処理結果を返却します。

パターン2:SAML認証

SAMLは、ユーザー認証結果を別のシステムへ安全に伝えるための仕組みとして、企業システムやシングルサインオン(SSO)で広く利用されているXMLベースの認証プロトコルです。SAMLは単なるログイン用途だけでなく、「外部システムへ一時的な権限を委譲する」用途でも利用されます。本例では、Keycloakで認証された結果をもとに、クラウド側が一時的なアクセス権限を払い出す構成になっています

そのため、SAMLはWebアプリのログインだけでなく、クラウドサービスやAPI連携における認証連携の基盤としても利用されています。

・SP(サービスプロバイダー):認証結果を受け取り、実際のサービスを提供する側(本図ではAmazon S3)
・IdP(アイデンティティプロバイダー):ユーザー認証を行う側(Keycloak)

アプリがKeycloakへリダイレクトし、認証後に「SAMLアサーション」と呼ばれる署名付きXMLが返却されます。アプリはこのアサーションを検証し、ログイン状態を確立します。

上記のシーケンス図は、KeycloakをIdP(Identity Provider)として利用し、オブジェクトストレージへファイルをアップロードするまでの一連の流れを示しています。ここでは、SAML認証と一時的な認証情報の払い出しがどのように連携するかを確認していきます。

① 認証認可サーバへのアクセス(SAML Assertionを要求)

まず、提供元業務システム(クライアント)はKeycloakに対して認証を要求します。ユーザー認証が完了すると、Keycloakはそのユーザーが正しく認証されたことを証明する「SAMLアサーション」を発行し、クライアントへ返却します。

② 一時的なセキュリティ認証情報を要求

クライアントは取得したSAMLアサーションを用いて、クラウド側の認証認可機能(AWS STSなど)へ一時的なセキュリティ認証情報の発行を要求します。このとき、SAMLアサーションは「このユーザーは正しく認証された」という証明書の役割を果たします。

③ SAML Assertionを検証

クラウド側の認証基盤は、Keycloakから発行されたSAMLアサーションの署名や有効期限を検証し、信頼できるIdPから発行されたものであるかを確認します。検証が成功した場合のみ、一時的なアクセス権限が付与されます。検証が完了すると、クラウド側は一時的なアクセスキーやセッショントークンなどの認証情報をクライアントへ返却します。これらは有効期限付きの一時的な権限であり、長期的な認証情報を保持する必要がないため、セキュリティの観点でも安全な構成になります。

④ Amazon S3へのアップロード

クライアントは取得した一時的な認証情報を利用して、オブジェクトストレージなどのリソースへアクセスします。ここではファイルアップロードなどの処理が行われます。

本構成では、ユーザーの本人確認(認証)はKeycloakが担当し、その認証結果をもとにクラウド側(AWS STS/IAM)がアクセス可能な権限を決定します。つまり、認証と認可の役割を分担した構成になっています。

まとめ:Keycloakは実務でも活用される認証基盤

Keycloakは単なる検証用ツールではなく、実際の業務システムやサービスにおいても広く利用されている認証基盤です。OpenID ConnectやSAMLといった標準プロトコルに対応しており、シングルサインオン(SSO)やAPI認証、システム間連携など、さまざまな場面で活用されています。

また、認証の仕組み(トークンの構造や認可の流れ)を実際に動かしながら理解できるという点でも非常に有用です。検証環境での学習用途から、本番環境での認証基盤としての利用まで、幅広い用途に対応できる柔軟性を持っています。

認証・認可の設計はシステム全体のセキュリティに直結する重要な要素です。Keycloakを利用することで、標準仕様に沿った安全な認証基盤を構築しつつ、運用コストや実装負荷を抑えることができます。

まずはローカル環境で動作を確認しながら基本的な仕組みを理解し、必要に応じて実際のシステムへ適用していくと良いでしょう。