<div dir="ltr"><div dir="ltr">On Mon, Aug 26, 2019 at 1:17 PM Wessel, Keith <<a href="mailto:kwessel@illinois.edu">kwessel@illinois.edu</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
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.<br>
<br>
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?<br></blockquote><div><br></div><div>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?</div><div><br></div><div>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?</div><div> </div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>I hope that's a sufficiently long non-answer.</div><div><br></div><div>Greg</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
Keith<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div></div>