The offline_access scope is defined as part of OpenID Connect, not as part of OAuth. There is no requirement that offline_access scope be the only way to have a refresh token issued, although some implementations have chosen to do this. My interpretation is that the offline_access is a partial misnomer - the user is only ‘offline’ in the sense of whether they currently have an authenticated session with the IDP.
The reason many OIDC implementations try to not return refresh tokens is that they want to have all authentication decisions flow through the user agent as potentially interactive. You can track user authentication within a refresh token, but this adds complications such as requiring persistent state within the application. The question is whether your app cares about current user authentication at the IDP. If your application either: - Uses IDP authentication more as a registration/account recovery to a local application account - Doesn’t care about IDP authentication but is just using the token for authorization purposes Then there isn’t a reason to go back through the web-based authentication process. Just do what you need to get a refresh token within the TOS of the IDP and go with that. IMO, the value of knowing active IDP authentication is reduced for mobile use cases, because (rightly or wrongly) users are expected to control access to the native applications through screen locks, passcodes, and biometrics. The primary user authentication is local and implicit in being able to open the app. The UX expectation is that further authentication challenges by remote services are to be done only as needed for their own CYA. If however you do want to rely on the IDP authentication, you’ll need to play within the process of the IDP chosen. Don’t request offline access, hope they give you a refresh token to use, and if not you’ll be popping up a browser pane (with a user consent on iOS 11+) every time the access token expires so the IDP can determine if the authentication still holds. And hope in the future that in the absence of offline_access, the IDP give a refresh token tracking the user authentication session, in order to reduce the frequency users are sent through that browser pane. -DW > On Sep 5, 2018, at 9:29 AM, Ron Alleva <ronallevat...@gmail.com> wrote: > > Hi all, > > I was looking around for guidance around how to refresh access tokens on > native mobile experiences. > > Suppose we’re using a normal OAuth auth code flow with a mobile app (Chrome > custom tabs/ASWebAuthenticationSession and all). Also, want to reduce the > interruptions to the end user. > > In general, it seems like refresh token is not the tool for the job, as it > generally implies offline_access, when the user is not there. So if the user > signed out of their identity provider, I would not want them to be able to > get a new access token. > > Via normal web flow, the “prompt=none” ability is available (called Silent > Authentication by Auth0), so the refresh can be done in the background, > without ever bothering the user at all if they are still logged in. I don’t > think this is possible with a chrome custom tab or iOS equivalent, even if > the user never needs to enter their password. > > Is there some type of similar flow for native mobile applications? It seems > like most of the suggestions out there refer to just using the refresh > tokens. Also, another note, SMART on FHIR seems to introduce the concept of > “online_access”, which seems to indicate a refresh token that is tied to an > authentication session. That also seems interesting to me. > > So anyway, is there any general guidance? Is everyone just using refresh > tokens? Some combination of long access tokens and longer web authentication > sessions? > > Thanks in advance, > > Ron > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
