Reasonable values for access token and refresh token lifetimes?

Greg Haverkamp gahaverkamp at lbl.gov
Mon Aug 26 19:58:31 EDT 2019


On Mon, Aug 26, 2019 at 1:17 PM Wessel, Keith <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
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190826/28127e16/attachment.html>


More information about the users mailing list