CODEWITHSUNDEEP
spring-securityspring-authorization-server
Scorpio76
Scorpio76

Reputation: 33

Spring authorization server: logout via Postman

I've managed to setup an OAuth2 identity provider using new Spring Authorization Server. To execute some tests, I used Postman - OAuth2 Authentication flow and I was able to get a JWT token without problems. Token Refresh also works perfectly out of the box. With the acquired token, I was able to secure an Api on another Spring Boot project, after a quite long trial-and-error process. Problem is, I've no idea about how to test logout process via Postman. Is there anyone who could help me, providing a link to any example ? Thank you in advance.

I'd expect the token to be invalidated after the process, so that it cannot be used anymore to secure API endpoints.

Upvotes: 0

Views: 1845

Answers (1)

ch4mp
ch4mp

Reputation: 12754

RP Initiated Logout is a standard way to invalidate user session on an authorization server with OIDC. Not all "OIDC" authorization servers comply with the spec when it comes to logout, but I think Spring's one does. Read the (short) spec to figure out how to find the logout endpoint URI from the .well-known/openid-configuration as well as how to build the logout request (method, params, etc.). With this elements, you should be able to build your Postman request to invalidate user session on the OP.

JWTs are immutable, you can't invalidate it (and even if you could, you'd never have the guaranty that you updated all the existing copies). It is valid from its issuance and until it expires. Period.

What you can invalidate are user sessions on:

  • the client. This usually goes with token deletion
  • the authorization server. When you do so, it should not be possible to:
    • get new access tokens with a refresh token issued before the logout (even if this refresh token is still valid)
    • introspect an access token issued before the logout (even if the access token is still valid)

If you can't trust the client to delete the access token when the user logs out and if the access tokens are not short lived enough to accept the risk of an access after logout, then you might have to switch the resource server from JWT decoding to token introspection. Yes, you can introspect a JWT, but no, introspection is not efficient at all.

As a side note, if you can't trust how client handles access tokens, you have a much bigger security issue than the remaining lifespan of access tokens after user logout...

Developed answer to the 1st comment

Login and logout are the responsibility of the client, not of the resource server, and REST API are resource servers (it should depend on spring-boot-starter-oauth2-resource-server and not of spring-boot-starter-oauth2-client.

My bet is the issue you are facing is not due to the access-token still being valid but that user sessions are still valid and that user login is done silently because of that => call the end_session_endpoint on the authorization server as described in the spec linked above (yes, you should follow the link and read the content).

You have several actions to take:

  • make sure your REST API is configured as a resource server (and not as a client) and remove login and logout from there. I have written quite a few tutorials on that subject.
  • configure an OAuth2 client for users login and logout. It could be:
    • the Angular application itself using a lib like angular-auth-oidc-client. This lib is well documented and easy to use, just follow the link and browse to the doc.
    • a Backend For Frontend (a middleware on your server keeping sessions for the Angular app, handling login and logout, fetching tokens from the authorization server, storing this tokens in session and then replacing session cookies with access token before forwarding a request from the browser to the API). spring-cloud-gateway can be used as BFF if configured as OAuth2 client and using the TokenRelay filter. I have a complete BFF implementation with spring-cloud-gateway (and Angular) in this specific tutorial from the collection linked above.

Whatever implementation you choose for the OAuth2 client (public in the browser or confidential on your server), it is its responsibility to trigger the RP Initiated Logout to invalidate the user session on the authorization server

  • the Angular lib I linked does it
  • if you choose an OAuth2 client implementation with spring, you can configure an OidcClientInitiatedLogoutSuccessHandler (or OidcClientInitiatedServerLogoutSuccessHandler in a reactive app) to redirect the user to the authorization server after the logout on your client so that both sessions are invalidated

Upvotes: 1

Related Questions