OAuth2.0・OpenID Connectの設計思考｜「誰が」「何に」アクセスするかで使い分けが決まる

「OAuth2.0とOpenID Connectは何が違うのか」——この問いに対して、プロトコルの仕様から入ると混乱しがちです。本記事では「誰が」「何に」アクセスするかという設計思考を軸に、2つのプロトコルの使い分けを具体的なシナリオで解説します。Spring Boot + Spring Securityの実装にも触れながら、認証・認可設計の考え方を体系的に整理します。

まず「認証」と「認可」を区別する

認証と認可は混同されやすい概念ですが、それぞれの役割は明確に異なります。

OAuth2.0は認可のフレームワークです。一方、OpenID ConnectはOAuth2.0の上に認証の仕組みを追加したプロトコルです。

OAuth2.0の用語・フローをより詳しく知りたい方はこちら。
認可の仕組みとして利用されるOAuth 2.0とは？用語・フローをわかりやすく解説

OpenID ConnectとID Tokenの仕組みをより詳しく知りたい方はこちら。
OpenID Connectとは？その仕組みと必要な知識とフローをまとめて解説

設計の出発点：「誰が」「何に」アクセスするかを問う

認証・認可を設計するとき、最初に考えるべきことは「誰が」「何に」アクセスするかです。この2つの問いへの答えが、使うべきプロトコルを決定します。

• 「誰が」がユーザー本人（未確定）→ 認証が必要 → OAuth2.0 ＋ OpenID Connect
• 「誰が」がアプリ自身（ログイン済み）→ 認証不要 → OAuth2.0のみ

シナリオで理解する：スケジュール管理アプリを例に

スケジュール管理アプリを題材に、2つの典型的なシナリオを見ていきます。同じOAuth2.0ベースのフローでも、scopeの設定によって目的と発行されるTokenが異なります。

シナリオA：ユーザーがスケジュール管理アプリにログインする

1. /dashboard アクセス（未ログイン）
2. 302 リダイレクト
3. scope=openid profile email でGoogleへ認可リクエスト
4. ログイン画面 ＋ 同意確認
5. 「許可する」
6. Authorization Code返却
7. Token交換（バックチャンネル）
8. ID Token(JWT) + Access Token返却
9. ID Token検証 → Session生成
10. ログイン成功 → ダッシュボード

発行されるToken：

• ID Token（JWT）＝ 誰がログインしたかの証明書（Spring Appが読む）
• Access Token＝ Google UserInfo APIへのアクセス権

シナリオB：スケジュール管理アプリがGoogleカレンダーにアクセスする

1. カレンダー取得要求
2. scope=calendar（openidなし）で認可リクエスト
3. 同意画面のみ表示（ログイン不要）
4. 「カレンダーへのアクセスを許可」
5. Authorization Code返却
6. Token交換
7. Access Token のみ返却
8. Access Token付きでAPIアクセス
9. カレンダーデータ返却

発行されるToken：

• Access Tokenのみ＝ Google Calendar APIへのアクセス権
• ID Tokenは不要（認証はSession管理済み）

2つのシナリオの比較

Access TokenとID Tokenの違い

Spring Boot + Spring Securityでの実装

Spring Securityの実装コードをより詳細に知りたい方は、OidcUserServiceのカスタマイズやResource Server設定まで解説した以下の記事をご覧ください。
Spring Boot + Spring SecurityでOAuth2.0 / OpenID Connectを実装する

application.ymlのscopeの設定が、OIDCを使うかOAuth2.0のみにするかを決定します。コメントアウトを切り替えるだけで、シナリオA・Bを使い分けられます。

spring:
  security:
    oauth2:
      client:
        registration:
          google:
            client-id: YOUR_CLIENT_ID
            client-secret: YOUR_SECRET
            # シナリオA（IdPログイン）：openidを含める → OIDC有効・ID Token発行
            scope: openid, profile, email
            # シナリオB（カレンダーアクセス）：openidなし → OAuth2.0のみ
            # scope: https://www.googleapis.com/auth/calendar.readonly

シナリオA：ログイン後のユーザー情報取得

scopeにopenidを含めた場合、Spring SecurityはID TokenをパースしてOidcUserオブジェクトを生成します。@AuthenticationPrincipalアノテーションでそのまま受け取れます。

@GetMapping("/me")
public Map<String, Object> currentUser(@AuthenticationPrincipal OidcUser oidcUser) {
    return Map.of(
        "sub",   oidcUser.getSubject(),
        "email", oidcUser.getEmail(),
        "name",  oidcUser.getFullName()
    );
}

シナリオB：Access TokenでカレンダーAPIにアクセス

OAuth2AuthorizedClientManagerを使うことで、Access Tokenの取得・有効期限切れ時の自動更新をSpring Securityに委譲できます。

// OAuth2AuthorizedClientManager が Access Token を自動管理・更新
OAuth2AuthorizedClient authorizedClient = authorizedClientManager.authorize(
    OAuth2AuthorizeRequest
        .withClientRegistrationId("google")
        .principal(authentication)
        .build()
);
String accessToken = authorizedClient.getAccessToken().getTokenValue();

Spring Securityが自動でやってくれること

次のステップ

本記事の設計思考をAWS Cognitoに適用した実践例はこちら。
認証・認可の仕組みを完全理解｜OAuth2.0・OpenID Connect・AWS Cognitoを初心者から実務レベルまで解説

まとめ：設計の思考順序

1. 「誰が」を確定する：未ログインなら認証が必要 → OIDCを使う。ログイン済みなら不要。
2. 「何に」アクセスするかを確定する：外部APIにアクセスするなら認可が必要 → Access Tokenが必要。
3. scopeを決める：認証が必要なら openid を含める。外部APIが必要なら対応するscopeを追加。

関連記事

• OAuth2.0の仕組みを理解する
• OpenID Connectの仕組みを理解する
• Spring SecurityでOAuth・OpenID Connectを実装する
• Authorization Code GrantとClient Credentials Grantの違い
• OAuth2・OpenID ConnectをAWS Cognitoで実践する

参考リソース

• Spring Security 公式 – OAuth 2.0 Login
• OpenID Connect Core 1.0 仕様
• RFC 6749 – The OAuth 2.0 Authorization Framework