What should I expect from the logout ?

[GBincaz]

Hi, thank you for sharing this repo, I have to migrate my old spring oauth2 dependencies mechanism and it was a great example to follow to set up a BFF architecture.

I'm working on the logout right now and while there is no more curent user returned by the security context, the cookies are still present in the following request after the logout, calling my resource server with those cookies still return datas, I can see the corresponding jwt tokens are still authenticated.

I have the same OidcClientInitiatedServerLogoutSuccessHandler used in the http.logout of the BFF, the authorization server is the spring one but its a http.oidc with default configuration and I can see the end_session_endpoint.

So I'm wondering what I should expect from logout and how I can clear the cookies and revoke the tokens.

[ch4mpy]

You cannot revoke JWTs which always are read-only, but it's ok as long as this JWTs are given only to actors that you can trust to be "stateless" (like your resource servers), or actors which you can trust to delete tokens when they end a user session (like your BFF and authorization server) .

What you should do is terminate the user session at two places:

• on the OAuth2 client(s) with oauth2Login (the BFF)
• on the authorization server (so that new tokens are not emitted silently on the next authorization code flow, which would make the user feel like he did not log out from the BFF)

By setting the OidcClientInitiatedServerLogoutSuccessHandler, you're asking the BFF to create the URI to logout the user from the authorization server using the end_session endpoint. This URI is set in the Location header of the response to the POST request you probably already send to your BFF.

What can go wrong in your case is:

• the response to the BFF logout is in the 2xx range and the frontend doesn't follow the Location header
• the response to the BFF logout is in the 3xx range, so the frontend user-agent automatically follows the Location header but some security mechanism on the authorisation server (XHR?) rejects the request because of its origin.

As you are writing only about OidcClientInitiatedServerLogoutSuccessHandler, my bet is that you are in the second case (302 response from the BFF and failing end_session request on the authorization server.

What you should check:

• make sure that the response after the BFF logout success handler is in the 2xx range
  • If you're using "my" starter, there's a com.c4-soft.springaddons.oidc.client.oauth2-redirections.rp-initiated-logout property that you can set to something like ACCEPTED for that
  • If you're not using "my" starter, inspect closely the security conf in the bff-gateway-official module, you'll find a SpaLogoutSucessHandler which wraps the OidcClientInitiatedServerLogoutSuccessHandler to change the status of the response
• in the frontend, parse the Location header in the response to the logout request and set the frontend window.location.href with this end_session URI so that the request to the authorization server is sent with the right origin

[GBincaz]

Tank you again for your detailed response!

I had indeed a couple of problems:

• As you mentioned I wasn't redirecting properly to the logout url sent back from the BFF
• I didn't registered in the client the post redirect url I was using in the LogoutSuccessHandler
• My access token was already expired when I was calling the logout endpoint resulting in an exception with the id_token_hint parameter automatically generated in the logout url

I'm preoccupied by the latter because I am using a refresh token grant type on top of the authorization code, allowing me to keep access token lifespan short and relying on the refresh token.
So I'm wondering if I should remove the refresh token entirely in favor of a longer access token validity.
And I guess I will need my front to deal with edge cases when access token has expired, since logout have no sense at that moment.

[ch4mpy]

No, you should keep short lived access tokens for security reasons. Plus, as per its name, the id_token_hint contains the ID token, not an access token (ID tokens can reasonably be longer lived than access tokens).

What you could do is what I do in the BFF tutorial Angular app: when the user info is fetched, read the exp (expiration time in epoch seconds), and plan a user info refreshing just before this expiration. This forces the tokens refreshing.

[GBincaz]

I tried to refresh the token just before the logout but I still get the exception.
I found that the problem is that when I refresh an expired access token, the oidc_id_token changes in the AuthorizationServer, but my BFF client isn't aware of it.
So when I call my logout endpoint the BFF client use the first oidc_id_token as parameter but it doesn't exist anymore since the value have been updated when the AuthentificationServer refreshed the accesss token.
I haven't found how to correct it yet but I'm still searching.

[ch4mpy]

What is your authorization server?

What scope does your client request in the initial authorization_code request and then in its refresh_token request?

[GBincaz]

I'm using the spring's authorization server:

OAuth2AuthorizationServerConfiguration.applyDefaultSecurity(http);

http.cors(withDefaults())
	.getConfigurer(OAuth2AuthorizationServerConfigurer.class)
	.oidc(withDefaults());

My client's scopes on both side are configured with "openid" and "profile".
AS

        RegisteredClient client = RegisteredClient.withId("1")
                                                  .clientId(clientId)
                                                  .clientSecret(clientSecret)
                                                  .clientAuthenticationMethod(ClientAuthenticationMethod.CLIENT_SECRET_BASIC)
                                                  .redirectUri(gatewayUri + "/login/oauth2/code/myoauth2")
                                                  .postLogoutRedirectUri(gatewayUri + "/ui/login")
                                                  .authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE)
                                                  .authorizationGrantType(AuthorizationGrantType.REFRESH_TOKEN)
                                                  .scope(OidcScopes.OPENID)
                                                  .scope(OidcScopes.PROFILE)
                                                  .tokenSettings(TokenSettings.builder()
                                                                              .accessTokenTimeToLive(Duration.ofMinutes(2))
                                                                              .refreshTokenTimeToLive(Duration.ofHours(4))
                                                                              .build())
                                                  .build();

BFF

spring:
    security:
        oauth2:
            client:
                provider:
                    spring:
                        issuer-uri: ${backend-uri}
                registration:
                    spring:
                        provider: spring
                        client-id: ${client-id}
                        client-secret: ${client-secret}
                        authorization-grant-type:
                            - authorization_code
                            - refresh_token
                        redirect-uri: ${gateway-uri}/login/oauth2/code/myoauth2
                        scope:
                            - openid
                            - profile
            resourceserver:
                jwt:
                    issuer-uri: ${backend-uri}

I can see that the scope attribute is present as a parameter with my GET request to the authorize endpoint.
For the refresh request I can only see one POST request to oauth2/token and that the postData of the request contains 3 parameters grant_type=refresh_token, refresh_token, and redirect_uri.

[ch4mpy]

As per OpenID specification, the scope for refresh token is offline_access. You should add it.

Also, as you seem rather new to OpenID / OAuth2, you'd probably better take an already complete solution (Keycloak or a cloud offer), rather than a do-it-yourself one like spring-authorization-server. This will save you (and others) weeks, if not months.