独学でJavaを学んでいる方向け

「実務レベルに到達できるか不安」「1人だと詰まることが多い」場合は、実践重視で学べる環境を一度確認しておくのも一つの手です。

EBAエデュケーション｜学習内容・サポートを見る

Spring SecurityのOAuth2構成を完全解説！ClientとResource Serverの違いとJWT連携の基本

OAuth2 Client／Resource Server基礎：構成と役割の違い（JWT連携の前提）

先生と生徒の会話形式で理解しよう

生徒

「OAuth2のClientとResource Serverって、なんだか役割が似ていて混乱しちゃいます…」

先生

「確かに名前だけ見ると分かりにくいですが、実ははっきりと役割が分かれているんです。」

生徒

「それぞれ何をするものなんですか？JWTとかアクセストークンとかも関係あるんですよね？」

先生

「ええ、JWTとの関係も重要なので、OAuth2 ClientとResource Serverの違いから丁寧に見ていきましょう。」

1. OAuth2 Clientとは？

OAuth2 Clientとは、ユーザーの認証を外部の認可サーバー（例：Google、GitHub、Keycloakなど）に委ねる役割を持つアプリケーションです。Spring Securityにおけるspring-security-oauth2-clientの機能で、ログインボタンを表示したり、アクセストークンを受け取ったりします。

Clientはあくまで「ユーザーの代理で認可を得る存在」であり、実際のリソース（例えばプロフィール情報など）を取得するのが目的です。

OAuth2 Clientを使うことで、ログイン機能を簡単にGoogleログインやGitHubログインなどと連携できます。

2. Resource Serverとは？

Resource Serverは、アクセストークン（多くの場合JWT）を使って保護されたAPIリソースを提供する側のサーバーです。Spring Securityではspring-security-oauth2-resource-serverの機能が該当します。

クライアントから送られてきたトークンの内容を検証し、そのトークンが正当であればリクエストを通します。認可されたユーザーだけがAPIにアクセスできるようにします。

つまり、Resource Serverは「トークンを検証して、保護された情報を提供する役割」を担っているのです。

将来を見据えて、＋αのスキルを身につけたい方へ

JavaやLinuxを学んでいても、「このままで市場価値は上がるのか」「キャリアの選択肢を広げたい」と感じる方は少なくありません。

AIを学ぶならアイデミープレミアム

3. OAuth2 ClientとResource Serverの違い

両者の主な違いは次のとおりです。

OAuth2 Client：ログイン・認証のために外部と連携し、アクセストークンを取得する
Resource Server：送られてきたアクセストークンを検証して、APIへのアクセスを制御する

OAuth2 Clientは「認証者」であり、Resource Serverは「保護者」とも言えます。

4. JWT（JSON Web Token）との関係

JWT（ジェイダブリューティー）は、アクセストークンの形式としてよく使われるものです。Resource ServerはこのJWTを受け取って、署名や有効期限、クレーム情報（ユーザーID、ロールなど）を検証します。

JWTは暗号化されているわけではなく、Base64でエンコードされているため、情報を確認できますが改ざんはできません。

Resource Serverは、受け取ったJWTの中身を見て「誰がアクセスしているのか」「どんな権限を持っているか」を判断します。

5. Spring Securityでの構成例（Client編）

まず、OAuth2 ClientとしてGoogleログインを構成する場合は、application.ymlに次のように設定します。


spring:
  security:
    oauth2:
      client:
        registration:
          google:
            client-id: your-google-client-id
            client-secret: your-google-client-secret
            scope: profile, email

このように記述するだけで、Spring BootアプリはGoogleログインに対応するようになります。

6. Spring Securityでの構成例（Resource Server編）

Resource Serverとして動作させるには、受け取ったJWTを検証する設定を行います。


spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://your-auth-server.com

この設定により、Spring Securityは受信したリクエストヘッダーのAuthorization: Bearer トークンを自動で検証します。

7. OAuth2構成の全体図と役割

以下の図のように構成を整理すると分かりやすくなります。


Client（フロントエンドやバックエンド） 
   ↓ 認証リクエスト
Authorization Server（Google／Keycloakなど） 
   ↓ アクセストークン（JWT）発行
Client ← JWT → Resource Server（API）

このように、OAuth2 Clientがユーザーの代理で認証を行い、Resource Serverが受け取ったトークンを検証してアクセスを制限します。

8. OAuth2構成で気をつけるポイント

JWTには有効期限（exp）があり、期限切れには注意が必要です
署名の検証にはissuer-uriやjwks-uriなどの設定が正しくないと失敗します
アクセストークンはできる限り安全に取り扱う必要があります（Cookie保管NGなど）
ClientとResource Serverを同じSpringアプリで実現する場合は設定を分けて慎重に行う必要があります

特にマイクロサービス構成では、Resource Serverを複数立てる場合もあるので共通の署名キー管理が重要になります。

まとめ

OAuth2とSpring Security構成の全体像を振り返る

ここまで、Spring Securityを使ったOAuth2構成について、 OAuth2 ClientとResource Serverの違いを中心に、 JWTとの連携や役割分担を丁寧に見てきました。 OAuth2は一見すると登場人物が多く、設定項目も多いため、初心者にとっては難しく感じやすい認証・認可の仕組みです。しかし、それぞれの役割を正しく理解すると、全体の流れは非常に整理されたものだと分かります。

OAuth2 Clientは、ユーザーの代わりに認証を行い、外部の認可サーバーと連携してアクセストークンを取得する役割を持ちます。一方でResource Serverは、そのアクセストークンを受け取り、正当なリクエストかどうかを検証したうえで、保護されたAPIリソースを提供する役割を担っています。この役割分担を理解することが、 Spring SecurityのOAuth2構成を理解する最大のポイントです。

JWTを中心にした認証と認可の考え方

本記事では、アクセストークンとして利用されるJWTについても詳しく触れました。 JWTは署名付きのトークンであり、 Resource Serverはこの署名を検証することで、リクエストが信頼できるかどうかを判断します。 JWTの中にはユーザー情報や権限情報が含まれており、それを元にアクセス制御を行うのがSpring Securityの基本的な動作です。

重要なのは、JWTが「暗号化」ではなく「署名」によって安全性を保っている点です。そのため、トークンの中身は確認できますが、改ざんされていないことが保証されているという特徴があります。 Resource Serverはこの仕組みを利用して、誰が、どの権限で、どのAPIにアクセスしているのかを判断します。これにより、ステートレスでスケーラブルな認証構成が実現できます。

構成理解を深めるためのサンプルイメージ

最後に、OAuth2 ClientとResource Server、JWTの関係を設定と処理の流れを意識したサンプルで整理してみましょう。それぞれの役割が分離されていることを意識すると、 Spring Securityの設定内容も理解しやすくなります。


spring:
  security:
    oauth2:
      client:
        registration:
          example:
            client-id: example-client-id
            client-secret: example-client-secret
      resourceserver:
        jwt:
          issuer-uri: https://auth.example.com

このように、一つのSpring Bootアプリケーションの中でも、 OAuth2 Clientとしての設定と、 Resource Serverとしての設定は役割ごとに整理されます。実務ではこれらを別アプリとして分離することも多く、マイクロサービス構成では特に重要な考え方になります。

初心者が押さえておきたい実務視点のポイント

OAuth2とSpring Securityを実務で扱う際には、単に設定を写すだけでなく、なぜその設定が必要なのかを理解することが重要です。 ClientとResource Serverを混同してしまうと、認証が通らない、JWTが検証できないといったトラブルに直結します。

また、アクセストークンの取り扱いには常に注意が必要です。トークンの保存場所、有効期限の管理、署名キーの共有方法など、セキュリティに直結する要素が多く含まれています。 Spring Securityは多くを自動化してくれますが、構成を理解していなければトラブル時に対応できません。今回学んだOAuth2構成の基本は、そのような場面で必ず役立つ知識になります。

先生と生徒の振り返り会話

生徒

「OAuth2って難しい印象がありましたけど、 ClientとResource Serverの役割を分けて考えると、だいぶ整理できた気がします。」

先生

「それはとても良い理解ですね。 OAuth2は登場人物が多いですが、役割さえ分かれば流れはシンプルです。」

生徒

「JWTも、ただのトークンだと思っていましたが、署名やクレームの意味が分かってきました。」

先生

「JWTの仕組みを理解すると、なぜResource Serverがトークンを検証するだけで認可できるのかが見えてきます。」

生徒

「これからSpring Securityの設定を見るときも、どの役割の設定なのかを意識して読めそうです。」

先生