Vert.X auth decodeToken deprecated (OAuth2)

[Darren Jones]

The current vertx-auth Oauth2 Provider documentation still references decodeToken (see: https://vertx.io/docs/vertx-auth-oauth2/java/#_verifying_jwt_tokens) yet it (and the rxDecodeToken method) is marked as deprecated. The referenced replacement for decodeToken is the "AuthProvider.authenticate" method. However, this "authenticate" method does not do anything similar to the desired result of decodeToken as the purpose of the "authenticate" method is to contact an OAuth2 provider and redeem an authentication code for tokens whereas the "decodeToken" method takes in a token string and returns the decoded AccessToken object. 

I need to interrogate (in JWT String format) parts of an access token using the OAuth2 Auth Provider which is already loaded with the "well-known" configuration and signing keys to determine if an access_token is expired and/or to capture the "sub" value. 

Going forward after the "decodeToken" method deprecation has been finalized and it is removed, how should I properly decode the token string and view its parts?

From comments in other posts in this forum related to this method being deprecated, but I'm still confused how to go forward.

[Darren Jones]

Anyone?

[Paulo Lopes]

The decode token is deprecated because it's result is not guaranteed to be valid. A valid token (just by checking the signatures and timestamp) can still be invalid if it has been blacklisted by the oauth2 server. This is the reason why it now fallbacks to the authenticate method internally.

If you already have the token parsed into a User object or a AccessToken object then you can get it's internal properties.

[Darren Jones]

The use case from which I am asking this is when the token is stored on a session in its String form. The token is then pulled off the session and we are trying to check to see if it is expired. We are managing multiple tokens as we are accessing multiple applications (auth server, resource server, etc each with their own access token). 

How should we parse/evaluate tokens without us having to go through the headaches of managing all of the well-known/keys/etc. separate from the already configured OAuth2Auth instance?

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/7b269fe0-3965-447b-90ba-478d6fd730ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paulo Lopes]

Ok, let me see if I understand it correctly, you want to decode a token that you trust, so it does not need to be cryptographic verified. Also you don't have the keys of the server to do the verification (if I read it right)...

In that case I think you're looking for: https://github.com/vert-x3/vertx-auth/blob/master/vertx-auth-oauth2/src/main/java/io/vertx/ext/auth/oauth2/KeycloakHelper.java

This helper decodes and doesn't verify anything (so use it with caution).

On Monday, May 6, 2019 at 5:02:47 PM UTC+2, Darren Jones wrote:

The use case from which I am asking this is when the token is stored on a session in its String form. The token is then pulled off the session and we are trying to check to see if it is expired. We are managing multiple tokens as we are accessing multiple applications (auth server, resource server, etc each with their own access token). 

How should we parse/evaluate tokens without us having to go through the headaches of managing all of the well-known/keys/etc. separate from the already configured OAuth2Auth instance?

On Mon, May 6, 2019 at 10:53 AM Paulo Lopes <pml...@gmail.com> wrote:

The decode token is deprecated because it's result is not guaranteed to be valid. A valid token (just by checking the signatures and timestamp) can still be invalid if it has been blacklisted by the oauth2 server. This is the reason why it now fallbacks to the authenticate method internally.

If you already have the token parsed into a User object or a AccessToken object then you can get it's internal properties.

On Monday, April 15, 2019 at 11:35:20 PM UTC+2, Darren Jones wrote:

The current vertx-auth Oauth2 Provider documentation still references decodeToken (see: https://vertx.io/docs/vertx-auth-oauth2/java/#_verifying_jwt_tokens) yet it (and the rxDecodeToken method) is marked as deprecated. The referenced replacement for decodeToken is the "AuthProvider.authenticate" method. However, this "authenticate" method does not do anything similar to the desired result of decodeToken as the purpose of the "authenticate" method is to contact an OAuth2 provider and redeem an authentication code for tokens whereas the "decodeToken" method takes in a token string and returns the decoded AccessToken object. 

I need to interrogate (in JWT String format) parts of an access token using the OAuth2 Auth Provider which is already loaded with the "well-known" configuration and signing keys to determine if an access_token is expired and/or to capture the "sub" value. 

Going forward after the "decodeToken" method deprecation has been finalized and it is removed, how should I properly decode the token string and view its parts?

From comments in other posts in this forum related to this method being deprecated, but I'm still confused how to go forward.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ve...@googlegroups.com.

[Darren Jones]

Sort of. 

We are operating within the "Api Gateway" pattern where the gateway is the one performing the processes of storing and validating the authentication responses for a user. Our authentication provider generates an initial authentication response (contains access_token, id_token, etc.) and then generates additional access_tokens for the various endpoints the from which the api-gateway needs to request information to complete the request from the client (a call from the client could require access to 1-to-many different information providers each of which need to have their own separate access_token to authenticate the user in that target system). The access_tokens for each of these endpoints could expire at different rates separate from the initial user authentication response. Since these are all created from the same authentication provider, the keys via the well-known are all the same and are already configured within the OAuth2 auth provider instance. 

We need a way to interrogate the various access_tokens to make sure they have not yet expired in case we need to ask for a new one. We would really prefer not to have to manage the well-known and key data in addition to the already-configured OAuth2 instance in order to validate a given token. The "decodeToken" seems to do this for us, but its deprecated status does not seem to provide a clear way forward if it is removed in future versions. Please advise (if you have, I apologize that I am not understanding what you have tried to explain).