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 <ronallevat...@gmail.com
<mailto: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
_______________________________________________
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
