JWT access token: How can I change the expiration?

[d1g1]

Hello Everyone,

I want to create an access token that is valid for a long time (for server-to-server API requests). I created a service account integration in the I/O Console following the documentation. After I generated the JWT, how can I set up the expiration date of the access token I create out of it?

“The expiration parameter is a required parameter measuring the absolute time since 01/01/1970 GMT. You must ensure that the expiration time is later than the time of issue. After this time, the JWT is no longer valid. At maximum, the expiration period can be set up to 24 hours from time of issue. Note: This is an expiration time for the JWT token and not the access token. Access token expiration is set to 24 hours by default.“

Is there a parameter I can include in the POST request to https://ims-na1.adobelogin.com/ims/exchange/jwt in order to set up the expiration date of the access token?

Thank you!

[settytb1 · Accepted solution]

Hi d1g1,

Unfortunately we only support 24 hour expirations currently.  As part of your application you will need to make sure getting a new token is part of the workflow. 

I hope that helps,

Seth

[d1g1]

Hi Seth,

thanks, that clears things up!

Although it is not the answer I hoped to get... I would prefer if I could set the expiration within the limitations of the underlying public key certificate.

[lenaf21917833]

settytb​: I prefer the same solution d1g1 mentioned: set the expiration with the underlying certificate, e.g. Is there any plan that this will become possible? Thanks!

[keremkulak]

So how do we refresh jwt token problematically? Looks like this is a company fail. We waited for a year to able to exchange jwt token for an access token but now you say you can support only 24 hrs.What should I do with 24 hrs if I need daily reports for my company, every day I should refresh it manually. This is a not solution. 

[JacobMiller]

Hi Seth,

Can you verify you work for Adobe?

It seems the quoted text has been updated since the initial time of this post:

https://www.adobe.io/authentication/auth-methods.html#!AdobeDocs/adobeio-auth/master/JWT/JWT.md

Has anything changed since the initial post of this question?

This documentation should state that 24 hours is the limit.

This also means that JWT access wasn't set up correctly since Adobe's response with the access token says their token expires in ~86400000 seconds, which is ~1000 days. Having an access token for a service account expire in 24 hours seems far from best practice for the same reason that Adobe encourages a quick expiration time for the JWT token. By having a short life on the access token, it means that an app will need to include the client secret/private key hard-coded in it without a few more round trips to some other dedicated server. And thus an exploit in the app means that additional access tokens can be created...

This seems far from best practices as far as information security is concerned.

[joshuab42862197]

Building on this, I think the 'expires_in' parameter returned in the access token response can be interpreted as milliseconds. At least I hope. Will be testing this.

[settytb1]

Hi Jacob,

If you look on that doc, the JWT should be very short lived.  See the Exp recommendation:

Required. The expiration parameter is a required parameter measuring the absolute time since 01/01/1970 GMT. You must ensure that the expiration time is later than the time of issue. After this time, the JWT is no longer valid. Recommendation: Have a very short lived token (a few minutes) - such that it expires soon after it has been exchanged for an IMS access token. Every time a new access token is required, one such JWT is signed and exchanged. This is secure approach. Longer lived tokens that are re-used to obtain access tokens as needed are not recommended.

Basically you need to make a new jwt then get a new access token.  That's really the workflow.  There's various libraries and sample code we have on how to generate a new jwt.

I hope that helps,

Seth

[JacobMiller]

Hi Seth,

The way that the JWT token works is that the JWT token is used to create access tokens. Where valid JWT tokens are compared against the certificate submitted to Adobe and this checks the authenticity of the request. Upon sending an authentic JWT token, an access token is returned which can be sent with API requests to access the Adobe resources.

Consistent with the documentation, the shorter-lived a JWT token is, the less likely it will be to create rogue access tokens.

For this reason, I even wrote my own script so that a JWT token expires in 60 seconds as versus the 24 hours on AdobeIO.

The access tokens are the ones that I am worried about. After sending a valid JWT token to get an access token, the payload states that access expires in 1000 days. However, I have been facing an issue where this token seems to expire in a day despite the response from Adobe's authorization server. This undesired behavior is not listed in the documentation. I am also concerned that giving the ability to create JWT access tokens to an app or automation is a security vulnerability because these access tokens are linked to the Tech account and not a user. For this reason, API usage is currently only using OAuth2, but once we automate some of our API requests, I would like to have a long-standing access token so that I do not have to give the automation platform the ability to create endless JWT access tokens.... For this same reason, it is not clear why we wouldn't just create a service account in AD, create a federated user, and then use an OAuth2 refresh token to keep authorization longer than the JWT access.

Is there a best practice moving forward for creating long-living access tokens?

[joshuab42862197]

I'm also having trouble getting this to work correctly. Following Adobe's guidelines, 'exp' should be set as POSIX time (seconds since the Epoch).

That can be implemented in Javascript like this: 

const thirtyMinutesFromNowInSeconds = (Date.now() / 1000) + 30 * 60;

However, changing the seconds affects the access token response very little. It seems that no matter what I enter, I get expires_in: 86399995 as the response.

Building on this, I think the 'expires_in' parameter returned in the access token response can be interpreted as milliseconds, not seconds. At least I hope, will be testing. Regardless, this puts the 'expires_in' date at 24 hours from now, no matter what my desired expiration is set to.

I see this as a security hole, especially considering their documentation states "Have a very short lived token (a few minutes)...This is secure approach. Longer lived tokens that are re-used to obtain access tokens as needed are not recommended." I hope Adobe fix this on this soon.