Azure AD B2C - Auth code flow vs implicit grant flow based on client types

Question

OAuth 2.0 spec defines confidential and public clients. https://tools.ietf.org/html/rfc6749#section-2.1

Here is the prescription according to the OAuth 2.0 spec

1. Confidential client - Web application - Auth code grant flow.
2. Public clients - Desktop App, Mobile App, SPA(Single page app) - Implicit flow.

However AD B2C's prescription according to Microsoft documentation is as follows https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-oauth-code

1. Confidential client - Web application - OpenIDConnect signin (Built on top of auth code grant)
2. Public clients - Desktop App, Mobile App - Auth code grant flow
3. Public clients - SPA(Single page app) - Implicit flow

Based on the above inference, we are clear with Web Apps and SPAs, no confusions here.

However for Desktop and mobile apps why is Microsoft suggesting Auth code grant flow instead of implicit flow [even though they are public clients according to Microsoft documentation as well]?

Answer 1

Posting the answer that i received from Microsoft, which i find as more appropriate in this case.

Please refer to https://tools.ietf.org/html/rfc8252#section-8.2 which says below -

The OAuth 2.0 implicit grant authorization flow (defined in Section 4.2 of OAuth 2.0 [RFC6749]) generally works with the practice of performing the authorization request in the browser and receiving the authorization response via URI-based inter-app communication. However, as the implicit flow cannot be protected by PKCE [RFC7636] (which is required in Section 8.1), the use of the Implicit Flow with native apps is NOT RECOMMENDED.

Access tokens granted via the implicit flow also cannot be refreshed without user interaction, making the authorization code grant flow -- which can issue refresh tokens -- the more practical option for native app authorizations that require refreshing of access tokens.

Answer 2

I believe the authorization code flow is being recommended for mobile and native apps so that a refresh token can be issued to these public clients.

The implicit flow does not issue a refresh token to a public client -- this flow requires the public client to send a hidden iframe request.

Answer 3

tldr: Authoirzation code flow is ideal for confidential clients. But it is not limited only for them;

Your perspective on client type and grant is not correct.

Confidential clients are the ones which can protect the client secret. For example, a web application with a secure back-end is one such. But a SPA cannot be considered one as it does not have a way to protect the client secret. SPA runs on a browser and observing the source from browser will reveal such secret if used. Same applies for a mobile app and a windows installed app (native). If you embed the client secret, then it can be obtained by some reverse engineering from the device.

Now about grant type, authorization code grant is suitable for any client which can do a back-channel token request. This token request happens outside the browser. This can be done by a mobile app or a windows app too. Also, there is PKCE specification dedicated to security enhance the flow for such native clients. If you read the spec, you will see that token request's client credentials are required only if client is confidential.

If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.

But SPA not having a back-end cannot perform the token request mentioned about. It runs on the browser. Thus implicit grant is defined to cater such apps.