Open ID Connect and native public app...no implicit flow, no hybrid flow...so what?

Question

We are currently developing a native mobile application, and we need to authenticate end-user with our identity server (made with thinktecture identity server v3), and/or external social identity providers, to consume some resources in our system.

We are trying to use OIDC to obtain access token and id token. In a perfect world, we want that native mobile application end-user remains logged indefinitely (even across native app reboots) until end-user decides to logoff.

So first, we have selected implicit flow. But we have discovered that refresh tokens are NOT available in this flow.

1. why implicit flow spec forbids refresh tokens ? where is the danger ?

2. To say it in other words, why token endpoint is not “reachable” with implicit flow ?

Then, we have tested hybrid flow to obtain refresh tokens (very very long-lived but revocable) and access token (short-lived). The problem is to embed a client_secret into a native public client. (bad and insecure practice as described by the OIDC specs)

3) So…native public app cannot use hybrid flow…huh?

So, we are currently wondering if a custom code flow solution is a good idea: Make a "proxy"/"front-end" web api that can reach the token end-point with his own secured client_secret and so, relays the code/refresh_token/access_token requests from the native client app to the authorization server token endpoint?

custom code flow picture

4) Any comments about this ?

Answer 1

The OAuth 2.0 Implicit grant is primarily meant as an optimization over the Authorization Code grant for in-browser clients that can't keep a client secret, hence it can be assumed that those clients also can't keep a refresh token a secret, at least over reboots, because the challenges are the same.

You could use an Authorization Code grant and register your native mobile app as a public client i.e. it would not have a client secret, just a registered redirect_uri.

Note that the refresh token does not have anything to do with the user login and it is not used to refresh user login state. You can only use it to get a new access token to use/act on the user's behalf. You may decide to consider the user logged in forever as an in-app only decision after the initial receipt of an id_token, unrelated to the state of the user at the Authorization Server (AS) or any of the tokens (access_token/refresh_token/id_token). If you'd want to take the login state at the AS into account you could send an authorization request with a prompt=none parameter and inspect the id_token or error in the authorization response.