OAuth2 for mobile apps with confidential backend client (Is PKCE required?)

Question

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.

Answer 1

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.

https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3

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.

Answer 2

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:

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