Application Types in OAuth

confidential, credentialed, and public

At OAuth, we talk briefly about the application type for some security features of the application.

OAuth 2.0 define 2 clients types.

1. Confidential
2. Public

These are based on the client’s ability to deploy a server secret. Or any type of credentials that can be used for authentication during the OAuth exchange.

So different between these 2 type applications,

1. Confidential client has the ability to be deployed with a client secret, that secret won’t be visible to anyone using the app. This is the pretty normal thing of apps running on the server app written in a server-side language, Java, .Net, PHP… And most of us very used to putting API keys in our application config or Environment variables and then expecting them to prevent secret.
2. However, this is not true for the public client. If you are writing a mobile app or a single-page application, and you are not able to include the secret in the application because users of the app able to see the secret, it is the most obvious point in the single-page application, so users of the app can always click on “View Source” in the browser and the secret can be found and there is no way to zip the secret of our source code. It’s a bit less obvious but also true with mobile app. Whether there is no “View Source” but plenty of apps are there to extract string out of the binary files.
3. Any type of application that runs the code with user control can not include the secret in that application.

Okay, so how do you decide what kind of application, and what to do with OAuth?

Well in OAuth, the application will be giving you get in with Authorization server. And if the application has credentials, the application can authenticate the request that makes that request.

This means that the OAuth server needs to know that the request can only request the actual application if the application’s credentials are included, without the credentials the authorized server will never know whether the making request by the real application or pretending to be something else.

The reason is this essential point, The authorization server might have different policies that making actively dependent on the type of client making the request. E.g., a confidential client, which s a first-party application. Since there may be a consent screen for what such a stream is, the authorized server can guarantee that only the actual application will end up with that flow and the access token.

However, first-part Public client, an attacker can emulate the application, coping its client ID and sort the stream. If they can control the redirect URL, they may end up with the access token. If the authorization thoughts that delivering to the real application. So in this case you can still include the consent screen to get the user involve in that flow.

Another thing is that the authorization server will depend on the type of client, whether to include token refresh or change token lifetime to minimize risk.

All these things are reason to use client authentication when possible, Actually two things are going on here,

• Not only whether the client can authenticate the request, but also whether the application can authenticate and whether the authorization server knows the identity of the application. These two different aspects of the same thing, actually is something in between a confidential and a public client.

And in OAuth 2.1 tentatively calling this a “Credential” client, The essential thing here is that it was already made in OAuth 2.0 and had no name before it.

• This type of client has credentials but whose identity has not been confirmed by the Authorization server.
• The simplest example is a mobile application, which, when first launched, uses dynamic client registration to obtain a client secret, since that first request may contain any authentication that is not a way to deploy that authentication into the app. So anyone can mimic the first registration step to get a client secret, however after receiving the client secret, they can use that client secret in a future request and tie together all the requests that particular instance of that app makes.
• Therefore, in this case the Authorization server still might use the policies of an unconfirmed, unidentified client, which will have token lifetime. But it can know the refresh token that is always released by the same client.

So in Summary,

1. Confidential clients are apps running on the server. That can be deployed with a client secret or other credentials
2. The public client cannot be deployed with the credentials, so the authorized server cannot actually guarantee that a request is being made to the public client or genuine or anyone else. The best thing as a client develops can do at any given time is to make sure you always choose the right type of application when registering your client and to protect your client secret / credentials when you release them. And never put a client secret into a mobile app or single page app.

That’s it :)