Resource servermedium3-5 years
A Spring Boot resource server is configured with only `spring.security.oauth2.resourceserver.jwt.issuer-uri`. In testing, a token the same identity provider issued for a *different* internal service is accepted, and `@PreAuthorize("hasRole('ADMIN')")` rejects every admin even though their tokens carry `"roles": ["ADMIN"]`. Explain both, in terms of what Spring actually configured.
The issuer-uri line builds a JwtDecoder that discovers the provider's keys and validates the signature, the issuer and the timestamps; it does not check the audience. A token for the other service is signed by the same provider with the same keys and has the same iss, so every check that runs passes. Adding an aud validator makes the service accept only tokens meant for it. The role problem is the claim mapping: by default Spring turns the scope (or scp) claim into authorities named SCOPE_... and ignores a custom roles claim, so the admin's Authentication has no ROLE_ADMIN, and hasRole('ADMIN') never matches. A JwtAuthenticationConverter that reads roles and adds the ROLE_ prefix fixes it.
PreviousAn SPA on `https://app.example.com` calls a Spring Boot API on `https://api.example.com` with `Authorization: Bearer ...` and JSON bodies. Without Spring Security it worked with `@CrossOrigin`; with Spring Security added, every call fails in the browser with a CORS error, yet `curl` with the same token works. Walk through what the browser is sending and what is rejecting it.Next A front-end team signs users in with OpenID Connect and sends the **ID token** to your Spring Boot API as the bearer token, because "it has the user's email and it's a signed JWT". Your API accepts it. What is wrong with the arrangement, which party is your API in OAuth terms, and what should the API check instead?