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

[David Waite]

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  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 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[George Fletcher]

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).


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



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Iain McGinniss]

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  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
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth