Reasonable values for access token and refresh token lifetimes?

[Wessel, Keith]

Hi, Greg and others,

Yes, Greg, you’re right: it’s a mobile app. They’re hoping for a refresh token lifetime of at least a month and ideally a year.

Regardless of that, does anyone know the answer to my second question? Does the OIDC extension to Shib allow for overriding refresh/access token lifetime values on a per-client basis?

Thanks,
Keith


From: users <users-bounces at shibboleth.net> On Behalf Of Greg Haverkamp
Sent: Monday, August 26, 2019 6:59 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Reasonable values for access token and refresh token lifetimes?

On Mon, Aug 26, 2019 at 1:17 PM Wessel, Keith <kwessel at illinois.edu<mailto:kwessel at illinois.edu>> wrote:

An app developer on our campus is asking us to increase the Shibboleth OIDC access token and refresh token lifetimes to 1 day and 1 month respectively. These are obviously much higher than the rather conservative defaults that ship with the OIDC extension.

Being quite new to OIDC, I thought I'd ask those on this list who might have been at it longer than a month or three... Are those reasonable defaults?

My personal opinion, regardless of the answer to your second question (whether they can change on a per-client basis), is that those are too long.  That said, I'm sure I only make that statement because of the nature of my OAuth and OIDC usage.  I assume from the nature of the question that the developer is more interested in OAuth than OIDC, and that the goal of lengthening the token lifetimes are to reduce the likelihood of having to prompt the user to reauthenticate and re-authorize?

Is this a server-to-server application?  I assume not, because the easiest thing would be for the developer to just refresh whenever access tokens were approaching expiration.  So, I gather instead that maybe it's a mobile application of some sort, and that the application isn't able to routinely refresh its tokens?

Most of our usage is OAuth for API access (Grouper, our identity management API's, and a couple of one-offs), along with some SPA's that use OIDC to authenticate and then access the identity API's.  In all cases, we keep the default expiration at 15 minutes, no referesh tokens, and we liberally revoke.  Among other things, user password changes happen over the API, and we revoke the access token as soon as a password change is completed.  In comparison, the Google API two-legged OAuth mechanism for Service Accounts grants access for 1 hour, no refresh tokens.

In general, I prefer to keep them short, but if the cost of data loss or "theft" is low, and it's configurable without a lot of overhead, I'm not sure that I see anything inherently wrong with longer windows.

I also presume I can change these on a per-client basis, but I don't see anything in the OIDC extension docs on how to do this. Is there a way?

Unfortunately, I don't know the answer to this.  I use a different OP/AS implementation, which grants to flexibility down to the individual token -- not that I've actually implemented this, though I have a current outstanding request to do so for one of my few non-IdM users.

I hope that's a sufficiently long non-answer.

Greg


Thanks,
Keith

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwMFaQ&c=OCIEmEwdEq_aNlsP4fF3gFqSN-E3mlr2t9JcDdfOZag&r=2ERBnv_hmATkLrFo9IGgSTIJkkZL1ljF18WCoTc8nrI&m=A7iR-q39mdhnb2Ctwg8TNVx-NdgWK47LB5iVsOWyeVE&s=qMlCvIOuEb2exBvXMr-ANQxyT-2DpFK8me8JQXI48SU&e=>
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190828/8e3df8f9/attachment.html>