rest-client-oidc-token-propagation & @AccessToken, fails locally if there's no access token #49362
-
|
As per the guide and also as seen in the source, the @accesstoken annotation will locally fail if it does not find a token . Why is a local reject done? It seems fine, but forces multiple rest clients to be created for the following scenario. Consider an api that has 2 end-points, 1 private and 1 public. Consider a consumer of this api, that has created a single rest client with both these end-points, and has added @accesstoken annotation at the class (its only at the class, and not at the method). Now the consumer has 2 endpoints as well, 1 public and 1 private. In this scenario, the public endpoint of the consumer cannot call the public endpoint of the api (because @accesstoken or rather filter aborts the request since it doesn't find the token). In a way it does seem logical for a local failure to be done (since the developer wanted to send an access token and there wasn't any), but a configuration would help reduce un-necessary splitting of restclients.. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 9 replies
-
|
/cc @cescoffier (rest-client), @geoand (rest-client), @pedroigor (oidc), @sberyozkin (oidc) |
Beta Was this translation helpful? Give feedback.
-
|
@akil-rails The OIDC token propagation tries to be non-ambiguous. If the API requirement is to pass access token then it must be passed, otherwise, if a REST client annotated with I agree having another REST client interface for a public API is not as optimal as making a single REST client interface combining multiple methods, but IMHO it is a safer option with a clean separation. If you'd like, instead of using |
Beta Was this translation helpful? Give feedback.
-
|
I get that, but returning a 401 locally from the client is misleading , since it's not returned by the remote service . |
Beta Was this translation helpful? Give feedback.
-
|
@akil-rails Well, the request is either allowed to go ahead or not, and since we agree on the purpose of |
Beta Was this translation helpful? Give feedback.
-
|
May be we can add a property to allow requests with tokens to proceed |
Beta Was this translation helpful? Give feedback.
-
|
That said, the access token may have to be exchanged... May be we can consider supporting |
Beta Was this translation helpful? Give feedback.
-
Yes, I agree that a method level annotation will help solve for authenticated and unauthenticated endpoints in a single rest client interface |
Beta Was this translation helpful? Give feedback.
-
|
Also, shouldn't @accesstoken respect the 'quarkus.security.auth.enabled-in-dev-mode' property? turning off authentication with rest client having @accesstoken , always fails with 401 as it doesn't find the accesstoken |
Beta Was this translation helpful? Give feedback.
-
Can you please create an enhancement request ? |
Beta Was this translation helpful? Give feedback.
-
I'm not sure right now, this feature is not about authenticating the incoming requests, while the property is related to the authentication process of the incoming requests. May be it is worth creating a runtime property allowing to disable the token propagation instead that will be set in the dev profile |
Beta Was this translation helpful? Give feedback.
-
|
quarkus.rest-client-oidc-token-propagation.enabled - i suppose this is the property that controls it - its just that its a separate parameter , so for now we are just setting it to the same value as quarkus.security.auth.enabled-in-dev-mode. |
Beta Was this translation helpful? Give feedback.
-
Done. #49878 |
Beta Was this translation helpful? Give feedback.
@akil-rails
Can you please create an enhancement request ?