-
Notifications
You must be signed in to change notification settings - Fork 244
AccessTokenContextRelay does not renew expired access tokens #223
Comments
Can you provide a complete, minimal, verifiable sample that reproduces the problem? It should be available as a GitHub (or similar) project or attached to this issue as a zip file. |
Hi @ryanjbaxter I'm trying to prepare the sample application but I'm struggling with the token relay configuration of the uaa service. According to the documentation https://cloud.spring.io/spring-cloud-security/reference/html/#_resource_server_token_relay all I need to do for token relay to work without
My client configuration looks as follows:
My
In order to fix this, I need to add the following to my uaa service:
Any idea what I'm doing wrong? Or am I just misunderstanding the whole idea and my uaa-service must be an client in order to be able to refresh an expired token? But than how can I refresh the token for a user which logged in via Here you can find the current sample state: https://github.com/HJK181/spring-oauth2 The downstream call I'm trying to test is: http://localhost:8080/uaa/downstream where I expect the token to be relayed from Zuul trough uaa down to resource2. |
Updated the sample. Found that I need to add The behavior is now as follows:
The subsequent request than returns an valid response until the token expires again, which will throw the NPE and so on ... The NPE is caused by the fact that I need to remove |
Nailed my initial problem down to
To fix this, I need to declare another http client, e.g. from Apache. Than token renewal with Hystrix does work. However I'M still facing the NPE from my last comment! |
The NPE looks like a problem in Spring Security, it does not look a problem with Spring Cloud Security (from what I can see in the stack trace). I suggest you open an issue there. |
That's a really disappointing answer/reaction after one week of waiting and a lot of time invested in providing you a minimal example and detail information whilst debugging the problem! I clearly pointed out several things which are not working here:
In general I'm really disappointed about the community support. You always ask the for sample applications, which you get in most cases, whilst tickets get prematurely closed without any help. If I point you to a bug I would expect you to open a ticket in other modules of the Spring ecosystem as it should be your interest of providing qualitative software to the community. @dsyer @spencergibb any constructive feedback on this? |
Looks like Ryan misread the NPE - there's a lot to grok, so don't blame him. If you have something working with apache http, then it's not really urgent, right (finding it hard myself to take in all the details)? |
Thanks for reopening @dsyer. Yes, appache http is somehow working. And I can totally live with the fact that I need to configure a different http client as I'm now aware of that However, even with the different http client, there's still the problem that as soon as the token relay get's passed an expired access token, it tries to use the refresh token to renew it, which will cause the NPE, thus leading to every X request to fail. I don't know how this should be solved as for the API-Gateway the access token might be valid at the time the request arrives but until it reaches the the relay that token might expire. Thus the token relay needs to use the refresh token to obtain a new access token but without authenticating himself via it's grant-type configuration. |
IMO the relaying party should pass the 401 back to upstream (i.e. never try to attempt to renew the token). I'm not sure that can be automated, but if you have any suggestions, please go ahead. |
This sounds reasonable for me. IF the upstream service is |
It depends on the HTTP client (not on whether it is using Zuul or SCG). But I think a well-behaved OAuth2 client should renew a refresh token if it knows about it. The Spring Security ones do try to IIRC. |
Spring cloud version: Greenwich.SR3
My UAA service is also an oauth2 client, which needs to relay JWT tokens coming in from Zuul. When configuring the oauth2 client the following way
I do get a 401 response from the downstream service as my access token has a very short validity and the
AccessTokenContextRelay#copyToken()
which get's executed by the autowiredResourceServerTokenRelayRegistrationAutoConfiguration
drops the validity and refresh token information.This leads to the following behavior:
OAuth2RestTemplate#getAccessToken
OAuth2RestTemplate#getAccessToken
but, as the access token populated byAccessTokenContextRelay
in theOAuth2ClientContext
does always return false foraccessToken.isExpired()
, the token is neither renewed nor doesAccessTokenContextRelay
refresh updated incoming access tokens. Instead the expired token is used again and again.The text was updated successfully, but these errors were encountered: