Subject: [OAUTH-WG] Mobile Native apps and renewing access tokens

From: Ron Alleva <[email-masked]>
Date: Wed, 5 Sep 2018 11:29:57 -0400

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

---

From: Iain McGinniss <[email-masked]>
Date: Wed, 5 Sep 2018 09:13:27 -0700

Hi, I'm the maintainer of AppAuth-Android, I've also cc'd William Denniss,
the maintainer of AppAuth-iOS and the author of the OAuth2 for Native Apps
BCP (BCP 212).

We recommend using the code flow to get a refresh token in order to
transparently acquire new access tokens as required, along with some other
recommendations in the BCP. There isn't a feasible alternative within the
spec for mobile apps, as repeatedly surfacing a browser tab is too
disruptive to the UX, and using an embedded web view is bad security
practice.

Whether the refresh token is "bound" to the lifetime of some other
revocable session is implementation specific, but if that implementation is
under your control you could tie the validity of the refresh token to that
of a web auth cookie, how recently it has been used, etc. There is no
reliable way of detecting browser state within an app without the user
interacting with a browser tab, unfortunately.

On Wed, Sep 5, 2018, 08:30 Ron Alleva <[email-masked]> wrote:

> 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.
>
> 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.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: George Fletcher <[email-masked]>
Date: Wed, 5 Sep 2018 13:42:51 -0400

I second the suggestion to use refresh_tokens even in an "online_access" 
model. You are correct that most Authorization Servers will grant 
offline_access to mobile apps because that produces a better user 
experience. However, if your requirements prohibit granting 
offline_access to the mobile app that doesn't preclude you from using 
refresh_tokens. Instead, the refresh_token is bound to a server side 
session and when the mobile app makes a refresh_token request and the 
server side session has expired, the refresh_token request fails and the 
mobile app knows it needs to ask the user to re-authenticate.

If tracking server-side sessions is a problem, you can also have the 
Authorization Server issue time-bound refresh_tokens (i.e. the 
refresh_token is only good for 90 minutes). The mobile app then 
refreshes it's access token as often as it needs until the refresh token 
flow fails at which point the mobile app asks the user to re-authenticate.

Hope that helps,
George

On 9/5/18 12:13 PM, Iain McGinniss wrote:
> Hi, I'm the maintainer of AppAuth-Android, I've also cc'd William 
> Denniss, the maintainer of AppAuth-iOS and the author of the OAuth2 
> for Native Apps BCP (BCP 212).
>
> transparently acquire new access tokens as required, along with some 
> other recommendations in the BCP. There isn't a feasible alternative 
> within the spec for mobile apps, as repeatedly surfacing a browser tab 
> is too disruptive to the UX, and using an embedded web view is bad 
> security practice.
>
> revocable session is implementation specific, but if that 
> implementation is under your control you could tie the validity of the 
> refresh token to that of a web auth cookie, how recently it has been 
> used, etc. There is no reliable way of detecting browser state within 
> an app without the user interacting with a browser tab, unfortunately.
>
> On Wed, Sep 5, 2018, 08:30 Ron Alleva <[email-masked] 
> <mailto:[email-masked]>> 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
>     [email-masked] <mailto:[email-masked]>

---

From: David Waite <[email-masked]>
Date: Wed, 5 Sep 2018 23:09:50 -0600

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 <[email-masked]> 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
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>