Why can't web application type 'Android' be a confidential client?

Question

Using authorization flow and passing the information to the back-channel for the token request we don't need to save the secret in the app.

Why then does Azure force us to use a public type?

Cannot choose for the app to be a 'web' type as the redirectUri is not allowed to be anything other than 'https://foo' which in our case is 'app://auth'

edit: More information

When adding a platform on Azure AD you currently have the option between

• web
• spa
• ios/macOS
• android
• mobile and desktop application

All of these are public clients except 'web' which can be confidential as the back-end is able to securely store the secret. My question is why is there a difference between web and for example an android application? The android app will communicate the exact same way a front-end application would. But choosing the android app is the only way I can configure the redirectURL for my application

An SPA being public is understandable, but forcing every mobile app to be public is something I do not understand

Answer 1

MOBILE FLOW

This has some differences to a web client. You are meant to use Authorization Code Flow (PKCE) without a client secret, and sign in via a Chrome Custom Tab. See this Curity tutorial for how that looks. Avoid using a web flow for a mobile client though.

MOBILE CLIENT SECRETS

Routing requests via an API that attaches a client secret is not considered standard since an attacker with your client ID and redirect URI could still trigger a flow on app:/auth.

If mobile client secrets are needed then the recommendation is to ensure a different client secret per device. This can be done using Mobile DCR. I don't think Azure supports this however.

HTTPS REDIRECT URIs

In case you're not aware, Android App Links are needed in order for mobile apps to receive authorization responses on HTTPS redirect URIs. I'm pretty sure Azure will support this, and it is a best practice since an attacker cannot get the response. More about this in a blog post of mine.

Answer 2

Using authorization flow and passing the information to the back-channel for the token request we don't need to save the secret in the app.

It sounds like you relate to a newer Client-Initiated Backchannel Authentication Flow. Azure does probably not support this flow, yet.

Why then does Azure force us to use a public type?

The confidential client and public client terms stems from OAuth 2.

• A confidential client is an application that is able to protect its client secret. E.g. a backend application in e.g. Java, Node.js or similar.

• A public client is an application that is not able to protect a secret - or where many unique instances exists. E.g. JavaScript Single Page Applications or Mobile applications - this is places where a Secret could be extracted in any client. It is now common to use a Proof Key for Public Exchange when using a Public Client.

Also see What's the difference between Confidential and Public clients? - OAuth in Five Minutes.