Implementing Login Authentication with Spring Cloud Gateway and JWT

The article builds on a previous Spring Cloud overview and demonstrates how to add JWT‑based login authentication to a micro‑service system, using the open‑source PassJava project as a reference implementation.

Key concepts such as authentication, authorization, and credentials are clarified before diving into the JWT workflow.

Authentication flow involves nine steps: user login, request forwarding to the gateway, credential verification by the authentication service, token generation (access_token and refresh_token), client token storage, token‑bearing requests, gateway token validation, user ID extraction, and business‑service processing.

Project structure includes the following services:

Authentication service: passjava-auth Gateway service: passjava-gateway JWT common module: passjava-jwt Member (business) service: passjava-member Nacos configuration center

The gateway routes authentication requests using a configuration like:

spring:
  cloud:
    gateway:
      routes:
        - id: route_auth
          uri: lb://passjava-auth
          predicates:
            - Path=/api/auth/**
          filters:
            - RewritePath=/api/(?<segment>.*),/${segment}

Login requests are sent to http://localhost:8060/api/auth/login (gateway) and forwarded to http://localhost:10001/auth/login (authentication service). The request body contains {"userId":"wukong","password":"123456"}. After successful verification, the authentication service generates JWT tokens using the utility class PassJavaJwtTokenUtil, which relies on the jjwt library.

Clients store the access_token (and optionally refresh_token) in cookies, local storage, or memory, and include it in the Authorization: Bearer <token> header for subsequent requests.

The gateway validates the token via a global filter JwtAuthCheckFilter, extracts the user ID, adds it to the request header, and forwards the request to the business service, which retrieves the member information based on the user ID.

Token refresh is handled by issuing both an access token and a longer‑lived refresh token. Clients can refresh tokens either proactively ("hungry mode") or after expiration ("lazy mode"). The refresh endpoint validates the existing token and issues a new access token, optionally invalidating the used refresh token by storing it in Redis.

Finally, the article summarizes that the tutorial covers authentication and credential handling, laying a solid foundation for future discussions on authorization.