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