How to set different token validity periods for different applications

Help
,
1

Hi everyone.

We are currently developing a product that has two types of login, one from a web application and the other from a native application, and we would like to have different validity periods for the bearer tokens for the web application and the native application.
Is this possible?
If so, we would like to know how to set it up.

2

Hey there @y-chibana !

Although it refers to SPA app, you may want to check this topic for reference - Auth0 SPA Session TTL

Thanks!

4

Thank you marcelina.barycka for your reply.

I have specified MaxAge for a WPF application built with .Net Framwrok 4.8, referring to your suggested post.

My assumed result was that the opening between iat and exp in the access token would be the MaxAge value, but that doesn’t seem to be the case.

The value of exp is the same as it was before I specified MaxAge, is this correctly adjusting the validity period?

5

Thanks for following up!
Would you mind sharing what Auth0’s SDK you use to adjust the /authorize request with the max_age (or maxAge) parameter?

Then we could dive into the library docs which could give us some good pointers.

This topic can be also relevant - How to enforce re-authentication for sensitive operations? - #2 by amaanc

Looking at the OIDC standard - specifying the max_age in the /authorize request results in the ID token being equipped with the auth_time claim.

max_age
OPTIONAL. Maximum Authentication Age. Specifies the allowable elapsed time in seconds since the last time the End-User was actively authenticated by the OP. If the elapsed time is greater than this value, the OP MUST attempt to actively re-authenticate the End-User. (The max_age request parameter corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] max_auth_age request parameter.) When max_age is used, the ID Token returned MUST include an auth_time Claim Value.

auth_time
Time when the End-User authentication occurred. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. When a max_age request is made or when auth_time is requested as an Essential Claim, then this Claim is REQUIRED; otherwise, its inclusion is OPTIONAL. (The auth_time Claim semantically corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] auth_time response parameter.)

If the auth_time Claim was requested, either through a specific request for this Claim or by using the max_age parameter, the Client SHOULD check the auth_time Claim value and request re-authentication if it determines too much time has elapsed since the last End-User authentication.

:video_camera: Prefer how-to videos instead of written docs? We’ve got you covered! Check out our OktaDev YouTube channel for those helpful resources!
—----------------------------------------------------------------------------------------------------------------------------

6

Thanks for getting back to me.

First, I would like to correct an error in my previous response.
The native app is built with WinForms, not WFP.

I am using version 3.5.0 of Auth0.OidcClient.WinForms, which is published as a Nuget package.

I thought this would be reflected in the access token exp, but after reviewing this response, I understand that this is incorrect.

I also confirmed that the ID token contains the result of auth_time.

However, a new question arises.
Since it is the access token that is sent from the native app to the API server, I don’t think the server can determine if the access token is still valid.

Is it not possible to check the specified validity period on the server side?

I know this is more of a general authentication mechanism than Auth0, but it would be helpful to know.

7

I think this article may bring some additional context.
Specifically the following statement:

This extra validation will need to be covered by application authors and frameworks making use of the max_age parameter.

Also:

Don’t rely on client-side verification (i.e. in the browser) of the ID token or auth_time to prevent sensitive operations.

(My interpretation) The middleware (on the API server side) responsible for the incoming access token validation and parsing could potentially make use of some of the relevant for the access token validation data, like:

  • time when the request to gain protected data has been sent;
  • “issued at” claim of the access token;
  • max_age parameter value;
  • “issued at” claim of the ID token;
  • “auth_time” claim in the ID token;
  • current time;

and perform validation by making relevant comparisons.

Does this give you some good directions for your investigation?

:video_camera: Want to join our next Community Interactive Q&A with our experts? This time we’re gonna talk about Auth0 Terraform Provider

8

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.