-
Notifications
You must be signed in to change notification settings - Fork 144
@EnableOAuth2Sso not taking care of refreshing the Access Token #5
Comments
Still struggling with this. There seems to be a lot of code in the Spring classes to handle refreshing of tokens, so I'm pretty sure our configuration is wrong somehow. I found out that DefaultTokenServices.loadAuthentication does reject access-tokens which are already expired. However, as soon as the access-token is accepted and the authentication information is placed in the SecurityContext, no further validation seems to happen on subsequent calls. I also found out this has nothing to do with the Zuul gateway. The important thing is that the browser is NOT sending tokens in the header. Instead the user is verified by the session-id. Our current approach can be found here: https://github.com/xdoo/lhm_animad_admin_api_gateway/tree/_%23197/src/main/java/de/muenchen/referenzarchitektur/apigateway What could it be we are missing so Spring Security does not check for expiry on every call? |
@rowe42 Can you please provide me a sample that reproduces this issue? This will be the most efficient method for troubleshooting. I'll take a look at lhm_animad_admin_api_gateway in the meantime and let me know if there are other repos to look at. |
@jgrandja Thanks for your reply! I've created a Spring Autorization Server with it so you will NOT need to install a KeyCloak server. Everything you need to run the showcase is included in the Repository. Please get back to me if you have any questions! |
@rowe42 Thanks for preparing the sample. The Take a look at the reference, as it states the following:
The main goal of The The I noticed your application is configured with I hope this clarifies things? I'm going to close this issue as |
Thanks for the exhaustive reply! I do understand what you are saying. |
I know that the OAuth2RestTemplate fetches new access tokens when calling the backend, e.g. Within a zuul gateway filter. However, this new access token does obviously NEVER replace the access token in the web session so the access token is basically refreshed on every backend call! |
After the user is authenticated via the I'm not familiar with the issue you are having with zuul gateway filter but you should log a ticket to the appropriate Spring Cloud project to address that if you require. |
execuse me , for the issue :spring-attic/spring-cloud-security#61 |
if use following code , direct not call refresh token ,
but default Oauth2RestTemplate will matain the refresh token to get new token. |
Not sure if this is still relevant for anyone, but using spring boot 2.0.5 and cloud Finchley.SR1 I observed the same problem. Took me quite some time, to figure out, that the OAuth2TokenRelayFilter only refreshes the token, if a OAuth2RestOperations is configured as bean.
Adding this, even when I do not use it explicity, sorted out the issue. The zuul proxy now refreshes the token as expected. |
It was also my observation that OAuth2TokenRelayFilter needs OAuth2RestOperations (or similar) in order to refresh the access token. In order to solve this we have in fact created a custom Zuul Filter, which does refresh the access token AND store it in the OAuth2Authentication. By doing so the OAuth2TokenRelayFilter will always get a valid access token. |
Hi @rowe42 |
Have same issue. |
Hi @rowe42 |
Hi, |
We are using a Spring Boot Application (in our case a Zuul Gateway) with the
@EnableOAuth2Sso
annotation. For this we are having a separate Auth Server, which delivers JWT-based Access-Token through the Authorization Code Flow.When accessing the application the first time, we are correctly forwarded to the Auth Server and back to the application after login, which then fetches the Access-Server as expected.
On subsequent calls to the Spring Boot Application this Forwarding is not executed, since the Access-Token is now bound to the Application Session.
However, what we do NOT see is that the Access-Token is inspected for validity (i.e. checking of the "exp" claim), so the Access-Token is never refreshed.
Note: When calling another Microservice in the backend through the Gateway, we see that the OAuth2TokenRelayFilter from @dsyer IS in fact refreshing the Access Token before calling the backend Microservice. However, this Access-Token is NOT replacing the expired Access-Token in the API-Gateway, which leads to a refresh of the Access-Token on EVERY backend-call (which of course is not correct).
What are we doing wrong? Is there some setting in the API-Gateway which we are missing?
We are having this bean, which doesn't help:
@dsyer Maybe you can give us a hint whether we are missing some setting somewhere?
The text was updated successfully, but these errors were encountered: