@Ethan-VisualVocal you can adjust your SSO session lifetime in your tenant settings, under the Advanced tab.
You said “I DO need to support SSO on iOS with Refresh Tokens.” Can you elaborate on what you expect a user interaction to look like for this?
As far as the two options I mentioned, you would implement one or the other…I think technically you could do both but there’s no benefit. If you didn’t want to set your global session timeouts to be short then you would use the second option.
max_age is an OIDC parameter that:
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. (https://openid.net/specs/openid-connect-core-1_0.html#rfc.section.220.127.116.11)
So it’s added as a parameter on the call to /authorize. I think to send it in Auth0.swift you would add it like this on the login method:
parameters: [max_age: "4900"])
With the caveat that I’m not an iOS developer and that might make your phone catch on fire. The idea here is:
- You record the time the user logged out of the app (or rather, the time they clicked “log out” and you revoked the refresh token)
- User tries to sign in again–you do some date math and determine it has been 5000 seconds since the token was revoked.
- You send a request to /authorize with max_age=4900
- Authorization server receives the request and sees that the user last logged in well over 4900 seconds ago (remember you revoked the token 5000 seconds ago so they logged in sometime before that)
- Authorization server requires the user to enter username/password again.
It’s important to note you’re doing this for user experience, not security. There’s nothing to stop the user or a proxy from tampering with the max_age parameter and reusing the SSO session. That is probably fine for this use case, but if you wanted to confirm the parameter was sent properly you would check the auth_time claim returned in the id_token and make sure it contains a sensible value.
Update: I should note this only applies to auth0 database connections. If you are redirecting to an upstream IdP (like Facebook), auth0 can guarantee that some sort of exchange with the upstream IdP took place, but we can’t guarantee the exchange involved a username and password (for example, the user may have had an existing session). So for an upstream IdP you can’t trust the auth_time claim to prove that the user provided a username and password.