🔒 Spring Framework 講座【特別編】クラウド時代のセキュリティ！〜OAuth 2.0/OIDCとKeycloakの連携〜

前回、API Gatewayを使ってマイクロサービスへのアクセスを一元管理する方法を学びました。マイクロサービス環境でGatewayが担う最も重要な役割の一つが、認証・認可の一元化です。

セキュリティはシステムの中核ですが、マイクロサービスごとに認証・認可のロジックを実装するのは非効率かつ危険です。そこで、専門の外部サービス（IDプロバイダ）に認証を任せる設計が主流となっています。

今回は、クラウド時代の標準的な認証・認可プロトコルである OAuth 2.0 と OpenID Connect (OIDC) の基本を復習し、これらをSpring Securityと連携させるためのオープンソースの代表的なIDプロバイダ Keycloak の概要と連携方法を学びます。

1. OAuth 2.0とOIDCの役割分担

第36回でJWTと合わせてOAuth 2.0について触れましたが、ここではその役割分担を明確にします。

プロトコル	役割	目的
OAuth 2.0	認可 (Authorization)	「誰に」「どのリソース」へのアクセスを許可するかを決定する。ログイン機能ではなく、アクセス権限を安全に委譲するためのもの。
OpenID Connect (OIDC)	認証 (Authentication)	「ユーザーが誰であるか」を検証し、ID情報（ユーザー名、メールアドレスなど）を安全に提供する。OAuth 2.0を拡張して認証機能を追加したもの。

結論: 現在のモダンなWebアプリケーションで「ログイン機能」を実装する場合、OAuth 2.0に加えて、OIDCプロトコルを利用してユーザーのIDを取得するのが標準です。

2. IDプロバイダ（Keycloakなど）の必要性

IDプロバイダ (Identity Provider) とは、認証を一手に引き受ける外部サービスです。代表的なものに、Okta、Auth0、そしてオープンソースのKeycloakがあります。

Keycloakの役割:
1. ユーザー管理: ユーザーアカウント、パスワード、二要素認証などの管理。
2. 認証処理: ユーザーからのログイン要求を受け付け、認証を行う。
3. トークン発行: 認証成功後、IDトークン (OIDC) と アクセストークン (OAuth 2.0) を発行する。
4. SSO (シングルサインオン): 一度のログインで、複数のアプリケーションへのアクセスを可能にする。

Spring Bootアプリケーションは、Keycloakに認証を任せることで、複雑なログイン処理の実装を完全に省略できます。

3. Spring SecurityとKeycloakの連携

Spring BootアプリケーションをKeycloakと連携させるのは非常に簡単です。Spring SecurityのOAuth 2.0/OIDCクライアント機能を利用します。

3-1. 依存関係の追加

Spring SecurityとOAuth 2.0クライアントの依存関係を追加します。

Groovy

dependencies {
    // Spring Security
    implementation 'org.springframework.boot:spring-boot-starter-security'
    
    // OAuth 2.0 Client/Resource Server機能
    implementation 'org.springframework.boot:spring-boot-starter-oauth2-client'
    implementation 'org.springframework.boot:spring-boot-starter-oauth2-resource-server'
    
    // ...
}

3-2. application.ymlによる設定

KeycloakのサーバーURL、アプリケーションのクライアントID、シークレット（秘密鍵）を設定します。

YAML

spring:
  security:
    oauth2:
      client:
        registration:
          # Keycloakに登録したクライアントのID
          keycloak: 
            client-id: my-spring-client
            client-secret: xxxxxxxxxxxxxx
            scope: openid, profile, email # OIDCとユーザー情報取得に必要なスコープ
            authorization-grant-type: authorization_code
        provider:
          keycloak:
            # KeycloakサーバーのURL (エンドポイントの自動発見に使用)
            issuer-uri: http://localhost:8080/realms/my-realm 
      # リソースサーバーとしての設定（JWT検証用）
      resource-server:
        jwt:
          # Keycloakの公開鍵の場所。発行されたJWTを検証するために必要。
          issuer-uri: http://localhost:8080/realms/my-realm

3-3. 認証のフロー（IDプロバイダ利用時）

リクエスト: ユーザーが保護されたAPI（例: /api/me）にアクセス。
リダイレクト: Spring Securityは認証されていないことを検知し、ユーザーをKeycloakのログイン画面に自動的にリダイレクト。
認証: ユーザーがKeycloakでログインIDとパスワードを入力。
トークン発行: Keycloakが認証に成功し、IDトークンとアクセストークンをSpring Bootアプリに渡す。
認証完了: Spring Securityがこれらのトークンを検証し、ユーザーを認証済みにする。

4. まとめ：セキュリティの「専門家」に任せる

Keycloakや他のIDプロバイダを利用する最大のメリットは、セキュリティの複雑性を専門家（IDプロバイダ）に任せられることです。特にマイクロサービス環境では、API Gatewayと組み合わせることで、全てのサービスのセキュリティポリシーを一箇所で管理・適用できるようになります。

この連携は、クラウド時代においてSpring Engineerが避けて通れない、必須の技術要素です。

✅ 本日のまとめ

OIDCは、OAuth 2.0を拡張し、**ユーザー認証（誰であるか）**の機能を提供する標準プロトコルである。
Keycloakは、認証・認可を一元管理し、SSOを提供するオープンソースのIDプロバイダである。
Spring Securityは、spring-boot-starter-oauth2-client を使ってOIDCの認証フローに準拠したログイン処理を自動で実行できる。
Keycloakの issuer-uri（発行者URI）を設定することで、Spring Securityがトークン検証に必要な公開鍵やエンドポイントを自動で発見し、連携を実現する。