Sa-Token's Same-Token Locks Down Internal Services from Direct Calls
Direct access to internal services is a common gap in microservice deployments, especially when network policies alone aren't enough. Same-Token adds a lightweight, framework-integrated enforcement layer that works across REST, Feign, Dubbo, and gRPC without an external auth server.
Microservices exposed behind a gateway still need a way to reject requests that bypass the gateway entirely. Sa-Token's Same-Token module solves this by injecting a short-lived shared token at the gateway and verifying it in every downstream service. The token lives in Redis, rotates on a schedule, and tolerates brief overlap between old and new tokens so that in-flight requests don't fail during a refresh. The same mechanism extends to internal RPC calls: Feign interceptors and Dubbo filters can attach and verify the token, blocking any caller that lacks it. A single YAML flag enables automatic token injection and verification for Dubbo and gRPC, while a manual filter approach gives teams room to attach custom metadata like tenant IDs.
Same-Token is effectively a lightweight alternative to OAuth2 client credentials for service-to-service auth, trading formal token endpoints for a shared secret rotated on a timer.
The dual-token overlap during refresh is a pragmatic design choice that avoids distributed coordination, but it means a compromised token remains valid until the next refresh cycle completes.
Sa-Token's Dubbo integration solves a real pain point: RPC calls in Dubbo strip out the HTTP context, so without explicit token propagation, any security check on the provider side fails with a null context error.
why does the application service still need to reference satoken? shouldn't only the login and gateway modules reference satoken
same-token itself has nothing to do with login and is not the same thing as a session token. same-token is only responsible for verifying the call source; it won't let through anything that isn't a gateway or internal RPC call.