Bearer Token

 Let’s walk through a concrete scenario step by step—an e-commerce app where a mobile client talks to two services: an Auth Service (issues tokens) and an Order Service (protects endpoints).

1. User Logs In and Gets a Bearer Token

Request to Auth Service

POST https://auth.myshop.com/login
Content-Type: application/json

{
  "username": "alice@example.com",
  "password": "P@ssw0rd!"
}

Response from Auth Service

HTTP/1.1 200 OK
Content-Type: application/json

{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "orders:read orders:write"
}

  • access_token is a JWT (JSON Web Token).

  • The client stores it (e.g. in memory or secure storage).

2. Client Calls a Protected Endpoint

Alice’s app now wants to fetch her orders:

GET https://api.myshop.com/orders
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

  • Note the header: Authorization: Bearer <token>.

3. Order Service Validates the Token

Under the hood, Spring Security’s Resource Server filter chain does this automatically:

  1. Extract the token from the Authorization header.

  2. Decode & Verify Signature

    • Fetch the public keys from the Auth Service’s JWK endpoint (e.g. https://auth.myshop.com/.well-known/jwks.json).

    • Use them to verify the JWT’s cryptographic signature—ensures it really came from your Auth Service.

  3. Check Standard Claims

    • exp (expiration): reject if expired.

    • aud (audience): must match “api.myshop.com”.

    • iss (issuer): must be “https://auth.myshop.com”.

  4. Populate Security Context

    • Extract scopes (e.g. orders:read) from the JWT’s scope claim.

    • Map them to Spring authorities (e.g. SCOPE_orders:read).

  5. Authorize the Request

    • Your HttpSecurity config says .antMatchers("/orders").hasAuthority("SCOPE_orders:read").

    • If Alice’s token has that scope, the call proceeds. Otherwise, she gets 403 Forbidden.

4. Order Service Responds

HTTP/1.1 200 OK
Content-Type: application/json

[
  { "orderId": 123, "total": 49.95, … },
  { "orderId": 124, "total": 19.99, … }
]

Alice sees her order list. All without ever sending username/password again—just the bearer token.

Key Points

  • Bearer means “anyone holding this token can use it.” Keep it secret!

  • JWTs are self-contained: you don’t need a database lookup on each request (just key lookup).

  • Validation = signature check + claim checks (+ optional revocation or introspection).

  • Spring Security’s resource-server support wires all this up with just a few lines of config.

Spring Security Config Snippet

@Bean
SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
  http
    .authorizeHttpRequests(auth -> auth
      .requestMatchers("/orders").hasAuthority("SCOPE_orders:read")
      .anyRequest().authenticated()
    )
    .oauth2ResourceServer(oauth2 -> oauth2
      .jwt(jwt -> jwt
        .jwkSetUri("https://auth.myshop.com/.well-known/jwks.json")
      )
    );
  return http.build();
}

  • .oauth2ResourceServer().jwt() turns on JWT validation.

  • .jwkSetUri(...) tells Spring where to fetch your Auth Service’s public keys.

This end-to-end flow—from login to token validation on each request—is the essence of using bearer tokens in real systems.

Comments

Post a Comment