0Pricing
Spring Boot 4 Complete Guide · Lekcja

Klient OAuth2 i przepływ kodu autoryzacji

Konfiguruj klienta OAuth2 w celu uzyskiwania i odświeżania tokenów za pomocą nadania kodu autoryzacji.

Klient OAuth2 i przepływ kodu autoryzacji to bezpłatna lekcja Spring Boot 4 Complete Guide na CoddyKit. To lekcja 2 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Spring Boot 4 Complete Guide, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Spring Boot 4 Complete Guide zawiera 4 lekcji w sumie.

Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.

Why an OAuth2 Client?

When your Spring Boot app needs to act on behalf of a user against an external provider (Google, GitHub, Keycloak, Okta), it becomes an OAuth2 Client.

The client never sees the user's password. Instead it redirects the browser to the provider's authorization endpoint, the user logs in there, and the provider hands back an access_token (and optionally a refresh_token) that the client uses to call protected APIs.

  • Authorization Code grant is the recommended browser-based flow.
  • Spring Security's spring-boot-starter-oauth2-client implements the entire dance for you.

Adding the Starter

Bring in the OAuth2 client support. In Spring Boot 4 this lives in spring-boot-starter-oauth2-client, which transitively pulls in spring-security-oauth2-client and the JOSE/JWT libraries needed for OIDC.

This Maven dependency is all you need to enable login-with-provider and token acquisition.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-oauth2-client</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Registering a Client via Properties

The fastest way to register a provider is through application.yml. Spring auto-binds these into a ClientRegistration.

  • client-id / client-secret — issued by the provider.
  • scope — openid, profile, email for OIDC login.
  • authorization-grant-type — authorization_code.
  • redirect-uri — the callback Spring exposes, usually {baseUrl}/login/oauth2/code/{registrationId}.
spring:
  security:
    oauth2:
      client:
        registration:
          keycloak:
            client-id: spring-app
            client-secret: "${KEYCLOAK_SECRET}"
            authorization-grant-type: authorization_code
            scope: openid, profile, email
            redirect-uri: "{baseUrl}/login/oauth2/code/{registrationId}"
        provider:
          keycloak:
            issuer-uri: https://auth.example.com/realms/demo

Issuer Discovery vs. Manual Endpoints

For OIDC providers, setting issuer-uri lets Spring fetch the /.well-known/openid-configuration document at startup and auto-discover the authorization, token, JWK set, and userinfo endpoints.

For plain OAuth2 providers without discovery (e.g. classic GitHub), you must specify the endpoints yourself.

spring:
  security:
    oauth2:
      client:
        provider:
          github:
            authorization-uri: https://github.com/login/oauth/authorize
            token-uri: https://github.com/login/oauth/access_token
            user-info-uri: https://api.github.com/user
            user-name-attribute: id

Enabling oauth2Login in SecurityFilterChain

Wire the flow into your SecurityFilterChain. Calling oauth2Login() activates the full Authorization Code flow: unauthenticated requests get redirected to the provider, and the callback is handled automatically.

This is framework configuration, not a standalone program.

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/", "/error").permitAll()
                .anyRequest().authenticated())
            .oauth2Login(Customizer.withDefaults());
        return http.build();
    }
}

The Authorization Code Flow Step by Step

Once oauth2Login() is active, here is what happens behind the scenes:

  • 1. User hits a protected URL; Spring redirects the browser to /oauth2/authorization/{registrationId}.
  • 2. Spring sends the browser to the provider's authorization endpoint with response_type=code, state, and a PKCE code_challenge.
  • 3. The user authenticates and consents at the provider.
  • 4. The provider redirects back to /login/oauth2/code/{registrationId} carrying a one-time authorization code.
  • 5. Spring exchanges that code (server-to-server) at the token endpoint for tokens.

The browser never sees the access token in step 5 — it's a back-channel call.

Accessing the Authorized Client and Token

After login, the access token is stored in an OAuth2AuthorizedClient. Inject it with the @RegisteredOAuth2AuthorizedClient argument resolver to read the token your app obtained.

This token is what you attach when calling the downstream resource server.

@RestController
public class ApiController {

    @GetMapping("/token")
    public String token(
            @RegisteredOAuth2AuthorizedClient("keycloak")
            OAuth2AuthorizedClient client) {
        OAuth2AccessToken accessToken = client.getAccessToken();
        return "type=" + accessToken.getTokenType().getValue()
             + " expires=" + accessToken.getExpiresAt();
    }
}

Calling APIs with RestClient and the Token

Spring Boot 4 favors RestClient. Configure it with the OAuth2ClientHttpRequestInterceptor so it automatically attaches the bearer token from the authorized client (and refreshes it when needed).

  • The interceptor reads the registration id from the request attributes.
  • No manual Authorization header building required.
@Bean
RestClient restClient(OAuth2AuthorizedClientManager manager) {
    OAuth2ClientHttpRequestInterceptor interceptor =
        new OAuth2ClientHttpRequestInterceptor(manager);
    interceptor.setPrincipalResolver(
        new SecurityContextHolderPrincipalResolver());
    return RestClient.builder()
        .requestInterceptor(interceptor)
        .build();
}

The Authorized Client Manager

The OAuth2AuthorizedClientManager is the engine that obtains, caches, and refreshes tokens. You configure a provider chain describing which grants it supports.

Enabling refreshToken() here is what makes silent token renewal possible when an access token expires.

@Bean
OAuth2AuthorizedClientManager authorizedClientManager(
        ClientRegistrationRepository clients,
        OAuth2AuthorizedClientRepository authorizedClients) {

    OAuth2AuthorizedClientProvider provider =
        OAuth2AuthorizedClientProviderBuilder.builder()
            .authorizationCode()
            .refreshToken()
            .build();

    DefaultOAuth2AuthorizedClientManager manager =
        new DefaultOAuth2AuthorizedClientManager(clients, authorizedClients);
    manager.setAuthorizedClientProvider(provider);
    return manager;
}

How Refresh Works

To refresh tokens, two things must be true:

  • The provider issued a refresh_token — this typically requires the offline_access scope (Keycloak) or an offline grant.
  • The access token is expired (or within the configured clock skew) when the manager is next asked for the client.

When you call the API through a token-aware RestClient, the RefreshTokenOAuth2AuthorizedClientProvider detects expiry, posts grant_type=refresh_token to the token endpoint, and transparently swaps in the new access token. No user redirect is needed.

spring:
  security:
    oauth2:
      client:
        registration:
          keycloak:
            scope: openid, profile, offline_access
            authorization-grant-type: authorization_code

Modeling Token Expiry in Plain Java

The refresh decision boils down to comparing an expiry Instant against now, allowing for a clock-skew buffer. Here is that core logic as a complete standalone program you can run to see when a refresh would trigger.

import java.time.Duration;
import java.time.Instant;

public class Main {
    static boolean shouldRefresh(Instant expiresAt, Instant now, Duration skew) {
        return expiresAt == null || now.isAfter(expiresAt.minus(skew));
    }

    public static void main(String[] args) {
        Instant now = Instant.parse("2026-01-01T10:00:00Z");
        Duration skew = Duration.ofSeconds(60);

        Instant valid = now.plusSeconds(300);   // 5 min left
        Instant nearly = now.plusSeconds(30);    // inside skew window
        Instant expired = now.minusSeconds(10);

        System.out.println("valid  -> refresh? " + shouldRefresh(valid, now, skew));
        System.out.println("nearly -> refresh? " + shouldRefresh(nearly, now, skew));
        System.out.println("expired-> refresh? " + shouldRefresh(expired, now, skew));
    }
}

Quick Check

You configured oauth2Login() and call a downstream API through a token-aware RestClient. The access token expires after 5 minutes, but users stay on the page for 30 minutes without re-authenticating. What single change most directly enables silent token renewal without sending the user back to the login page?

Recap

You configured Spring Boot 4 as an OAuth2 client driving the Authorization Code flow:

  • Starter: spring-boot-starter-oauth2-client enables the flow.
  • Registration: client-id/secret, authorization_code grant, scopes, and a redirect-uri; OIDC providers auto-discover endpoints via issuer-uri.
  • Activation: oauth2Login() performs the redirect, PKCE code exchange, and callback handling.
  • Using tokens: inject @RegisteredOAuth2AuthorizedClient or call APIs via a token-aware RestClient backed by an OAuth2AuthorizedClientManager.
  • Refresh: request a refresh-capable scope and build the manager with .refreshToken() so expired access tokens renew silently via grant_type=refresh_token.

Często zadawane pytania

Czy lekcja „Klient OAuth2 i przepływ kodu autoryzacji” jest bezpłatna?

Tak — pełny tekst „Klient OAuth2 i przepływ kodu autoryzacji” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Spring Boot 4 Complete Guide, przejdź na CoddyKit PRO. Kurs Spring Boot 4 Complete Guide zawiera 4 lekcji w sumie.

Co nauczysz się w „Klient OAuth2 i przepływ kodu autoryzacji”?

Konfiguruj klienta OAuth2 w celu uzyskiwania i odświeżania tokenów za pomocą nadania kodu autoryzacji. Ćwiczysz Spring Boot 4 Complete Guide z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Spring Boot 4 Complete Guide?

Nie wymagamy żadnego doświadczenia. Spring Boot 4 Complete Guide w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 2 z 4.

Ile czasu zajmuje lekcja „Klient OAuth2 i przepływ kodu autoryzacji”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Spring Boot 4 Complete Guide?

Tak. Każda lekcja Spring Boot 4 Complete Guide zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Weryfikacja JWT serwera zasobów i roszczeń
  2. Klient OAuth2 i przepływ kodu autoryzacji
  3. Bezpieczeństwo metod z SpEL i niestandardowymi voterami
  4. Introspekcja nieprzezroczystych tokenów i wymiana tokenów
← Powrót do Spring Boot 4 Complete Guide