OAuth2 and OIDCmedium3-5 years
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?
In OAuth terms the API is the resource server: it receives and validates access tokens; it does not issue them, and it is not the client. The client is the front end the user is using. OIDC issues three tokens with three audiences: the access token is for the resource server, the ID token is for the client (it tells the client who signed in), and the refresh token is for the authorization server. The ID token's aud is the client's id, so a correctly configured resource server rejects it; the API accepting it means its audience check is missing, and it is accepting a token that was never issued to authorize calls to it. The front end should send the access token, and the API should validate issuer, audience and expiry on it.
PreviousA 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.Next `AccountService.closeAccount(id)` is guarded with `@PreAuthorize("hasRole('ADMIN')")` and tests confirm a regular user gets 403 from the controller. Months later an audit finds accounts closed by non-admins. The call paths now include a Kafka listener and an `AccountService.processRequests()` method that calls `closeAccount` for each pending request. What are the ways this guard can be bypassed or misapplied, and how would you make the coverage provable?