 If you've spent any time reading up about OAuth, you've probably seen the terms Confidential Client and Public Client used a lot. What exactly do these mean and why should you care? Let's find out. Welcome to OAuth in 5 Minutes, a series where we deep dive on various topics around OAuth and OpenID Connect in just 5 short minutes. I'm your host Aaron Parecki and let's get right into today's video. So the first thing to remember is that Client is the OAuth spec term for application. It sometimes frustrates me that the spec has all these fancy names for things, like Client for application or Resource Owner for user. There is a good reason for it because technically a Resource Owner can be something other than a user, but for the vast majority of the time we're talking about users using applications. So if Client means application, then what do Confidential and Public mean? These are again kind of strange words to use, but they are defined in the spec, so we have to understand them. Basically the difference between Public Client and Confidential Client is that Confidential Client can keep a secret and Public Client can't. So basically what that means is that if you were to put something that's secret into a Confidential Client, then you can be sure that it will remain secret. Whereas if you try to put something that's a secret into a Public Client, it won't stay secret for very long. So let's look at some examples. Confidential Clients are typically applications that are running on a server, so that's going to be things written in server-side languages like .NET, Java, PHP, anywhere where you can define variables and config entries in the server-side environment and they will stay there and not be visible to users of the application. This is very different from Public Clients where this isn't possible. Probably the simplest example of a Public Client is a JavaScript application, also known as a Single Page Application. The way that works is when you go visit the application's website, it downloads the entire source of the application into your browser and then executes it there. What that means is that you can go into the Browser's View Source button and start looking around at all the code inside the application. And no matter how much the developer tries to hide things in there, there's no way to actually hide secret API keys if they will be visible to the end user of the application. Now, it's a little bit less obvious, but the same thing is also true for mobile apps. Of course, there's no View Source button on a mobile app, but there's plenty of tools available to take that binary file that's downloaded from the App Store and decompile and extract strings out of it. The problem is that the application is actually running on a device that the user is in control of, which means they can use a lot of tools to be able to extract things out of that application. Another example of this would be things like embedded devices or Internet of Things or even like your Apple TV. So sure, in this case, it's a lot harder to actually get into the binary of that application, but it is running on the user's network, which means they can always look at their own network traffic going across their connection in order to see whatever is being sent across the wire. The problem here is that this device is running on a network that the user controls, not that the application developer controls. Okay, so these are some examples of public clients versus confidential clients. Now, how does this relate to OAuth? Typically, when you start building a OAuth application, you're going to go to the developer website of the service you're trying to access and go register a new application. It's going to give you back a client ID and a client secret. These are like the applications username and password. The client ID is considered public. It's used in URLs. It's sent in the browser. It's visible to the user, but the client secret is like a password and it must be kept secret just like you would a password. So the secret is used in OAuth in the exchange of an authorization code for an access token. Now, we're not going to get into the whole OAuth flow in this video. We have some other videos to talk about that already. The thing that the secret does is it means that if someone was able to steal the authorization code out of the address bar, they would not be able to use it because they would not have the secret also. And the OAuth server then requires that the secret is present when the authorization code is exchanged. So the problem is that public clients can't use a secret. So what are we going to do instead? So it turns out that in order to complete an OAuth exchange with a public client, we actually have to do things a little bit differently. We can't ship a secret down to the application when the application is downloaded. So instead, what we do is when the application is ready to start an OAuth flow, it actually generates a secret on the fly for that particular exchange. It uses that secret when it initiates the OAuth flow. Then again, the OAuth server requires that secret when the authorization code is exchanged for the access token. This technique is called pixie or proof key for code exchange. And this is actually an extension to OAuth developed specifically for this case of doing OAuth in public clients. We'll do a deeper dive on pixie in a later video, but there's also some videos on this channel that you can check out right now that talk about pixie and the authorization code flow. So let's recap what we just learned. Confidential clients and public clients refer to whether or not the application has the ability to keep a secret. Confidential clients are typically going to be things that are running on a web server environment written in a server side programming language like .NET or Java. Whereas public clients are things that can't keep a secret because they are running in a device that the user controls. That's going to be things like a single page application or a mobile application. So with public clients, because we can't use pre-registered secrets, we instead have to do the authorization code flow a little bit differently using the pixie extension. And that's our five minutes. I hope you learned something today. As always, please give this video a thumbs up if you enjoyed it and subscribe for more videos like this. I'm Aaron Parecki. Thanks for watching and I will see you in the next one.