I'm wondering why neither rfc6749 nor rfc8252 seem to consider the case where the mobile app does not make protected resource requests (and is therefore not a client) but instead relies on a backend server (confidential client) that does.

*Note that I use the term mobile app instead of native app only because the spec defines a native app as being a public client:

From rfc6749

  • Section 2.1:

    A native application is a public client installed and executed on the device used by the resource owner. Protocol data and credentials are accessible to the resource owner. It is assumed that any client authentication credentials included in the application can be extracted. On the other hand, dynamically issued credentials such as access tokens or refresh tokens can receive an acceptable level of protection. At a minimum, these credentials are protected from hostile servers with which the application may interact. On some platforms, these credentials might be protected from other applications residing on the same device.

  • section 1.1:

    client - An application making protected resource requests on behalf of the resource owner and with its authorization

The case that I'm inquiring about is similar to how rfc6749 section 2.1 defines a web application, but instead of an HTML user interface, the interface would be a mobile app:

A web application is a confidential client running on a web server. Resource owners access the client via an HTML user interface rendered in a user-agent on the device used by the resource owner. The client credentials as well as any access token issued to the client are stored on the web server and are not exposed to or accessible by the resource owner.

rfc8252's definition of native app seems more reasonable as it doesn't restrict its use to apps that are public clients:

"native app" An app or application that is installed by the user to their device, as distinct from a web app that runs in the browser context only. Apps implemented using web-based technology but distributed as a native app, so-called "hybrid apps", are considered equivalent to native apps for the purpose of this specification.

But again, the spec only provides the best practice for the case where the native app is also the (public) client.

In summary,

  1. I'm wondering why I haven't been able to find any mention of the client profile I described above (either in the specs or elsewhere).
  2. Would the Authorization Code Grant (without PKCE) be considered secure enough since even if a malicious app intercepts the authorization code (sent by the external user-agent to the native app, via inter-app communication) it wouldn't be able to exchange it for an access token as it would not be in possession of the client secret which is stored on the backend?

Note that I'm only asking these questions to gain a better understanding of the theory, and not for anything practical.

2 Answers 2


The flow you describe is exactly what Google offers for mobile apps : https://developers.google.com/identity/protocols/CrossClientAuth

After looking in more detail the rfc 6749, we can note that this flow does not respect the recommendations.


The authorization server MUST:

o ensure that the authorization code was issued to the authenticated confidential client, or if the client is public, ensure that the code was issued to "client_id" in the request,

Indeed, the authorization code was issued to the native app, and it is the web application that tries to exchange the code.

It is up to the developer to decide if he wants to strictly respect the RFC and in this case use the flow Authorization code with PKCE then send the access token to the backend server so that it can access the resource server; or if he wants to use the same flow as google.

  • 1
    Very helpful information @Alex83690. The Android app obtains offline access for web back-end section in the Google link you provided does indeed describe the flow I'm inquiring about and I am very glad to have found official documentation describing it.
    – el_tigro
    Commented Jun 1, 2018 at 1:01
  • Although it is not clear whether or not Google uses PKCE under the hood for this flow, I would assume it doesn't since this particular flow does not seem to be the target of rfc8252, and rfc7636 (PKCE) makes it clear from the first line of the abstract that PKCE is meant to protect public clients.
    – el_tigro
    Commented Jun 1, 2018 at 1:07
  • One thing I found confusing about the documentation (unrelated to my initial question), is this requirement: Verify that the sub field in the ID token from Google is identical to the sub field in the ID token that it received from the client. It is not clear where the ID token from Google comes from. I assume the backend receives it along with the access_token and refresh_token, but it's not clear since the doc only says: The web component can exchange the code, as described in Handling the response, for an access token and a refresh token.
    – el_tigro
    Commented Jun 1, 2018 at 1:15
  • I agree: their documentation is not clear. But I think that on this point google respects the recommendations. The mobile application receives an id_token if the response_type contains "id_token" and the server receives it if the scope contains "openid". Here you have the Google API for Oauth in php. you will be able to examine their functioning : github.com/google/google-api-php-client/blob/master/examples/… github.com/google/google-auth-library-php/blob/master/src/…
    – Alex83690
    Commented Jun 1, 2018 at 7:37
  • "we can note that this flow does not respect the recommendations." I disagree with this statement. It is actually explicitely explained in the rfc > "The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices)." > A client may be implemented as a distributed set of components, each with a different client type and security context (e.g., a distributed client with both a confidential server-based component and a public browser-based component) Commented Dec 28, 2021 at 11:39

To begin with, the suggested context/scenario seems to be in compliance with the RFC, even more when considering this paragraph at 2.1. Client Types

A client may be implemented as a distributed set of components, each with a different client type and security context (e.g., a distributed client with both a confidential server-based component and a public browser-based component). If the authorization server does not provide support for such clients or does not provide guidance with regard to their registration, the client SHOULD register each component as a separate client.

I have found this article that gives a very nice explanation on a possible attack in such a configuration.

It is not very clear how to call all those apps and it's often ambigous (often we also call a SPA/native app a client for an API backend, but "confidential client" in the rfc would refer to the backend...), but I found the terminology/names used by the article quite explicit, so here's a recap with something similar

  1. You have a user Alice using a frontend app (a website or mobile/native app, SPA, etc)
  2. that requests an authorization code from your OAuth2 provider, for example by redirecting or opening a browser to the OAuth provider website
  3. during the OAuth callback phase, Alice browser/native app redirects to a URL/deep link on this same frontend app
  4. Alice frontend app sends Alice's code to your Trusted relying party (like a Rails API) with Alice credentials
  5. Your relying party exchanges the code with an access token, and links it to your connected user Alice

The problem is that, an attacker (Eve as in the article) could intercept your exchange with the trusted relying party with a man in the middle (a browser extension in the article, so not even "your fault"), and send a request with the same access code but for a different user, and step 4 becomes:

  1. Alice frontend app sends Alice's code to your malicious app
  2. the malicious app sends Alice's code to your Trusted relying party with Eve credentials
  3. Your relying party exchanges Alice's code with an access token to Alice's data, and links it to Eve
  4. Eve gains some access to Alice's data based on what your relying party provides

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .