1

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.

|improve this question
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://tools.ietf.org/html/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.

|improve this answer
  • 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. – catanman Jun 1 '18 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. – catanman Jun 1 '18 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. – catanman Jun 1 '18 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 Jun 1 '18 at 7:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.