What Is Pkce Grant Type in Oauth and How to Use It?

Check out this excerpt from the upcoming Book Club episode with  Aaron Parecki, author of the book OAuth 2.0 Simplified, and Eric Johnson, Senior Developer Advocate at AWS, where they guide you through some of the main reasons to use the framework, that has already become an industry standard, and what it takes to build a secure web server.

The OAuth 2.0 authorization framework has become the industry standard in providing secure access to web APIs. It allows users to grant external applications access to their data, such as profile data, photos, and email, without compromising security. OAuth 2.0 Simplified is a guide to building an OAuth 2.0 server. Through high-level overviews, step-by-step instructions, and real-world examples, you will learn how to take advantage of the OAuth 2.0 framework while building a secure API.

Buy the book
OAuth 2.0

Eric Johnson: Let's talk about client secrets for a minute. With the OAuth 2 spec, they're kind of removed, right? We're removing client secrets because we can't do them in SPAs, we can't do them in mobiles. There is some security that we can wrap around that. As I said I'd come back to it, is PKCE. So explain PKCE.

Aaron Parecki: Yes. With the authorization code flow, I stepped through a high level of it. The authorization code flow with the client secret is mostly secure, although it turns out that PKCE actually solves a very small attack even if you have a client secret still.

What PKCE does is PKCE basically creates a new secret for every request, for every initiation of the flow. When the app goes to start the flow, the app has to first create a new secret for that particular exchange. It uses that secret to calculate a hash of it that's sent out publicly. Then it has to use that secret when it goes and exchanges the authorization code.

Eric Johnson: Ok.

Eric Johnson: Ok.

Aaron: So effectively what it does is it means that the authorization code that gets returned in that response, without a client secret that could be used to get an access token. An attacker could steal that to get an access token.With PKCE it is no longer possible to steal it because the secret has actually never left the device during that whole exchange until it's actually used to get the access token.

Eric Johnson: Ok, that makes sense. So with PKCE the onus is on the client to invoke. Because what I'm seeing and did some reading on this is... Go ahead.

Aaron Parecki: No, go ahead.

Eric Johnson: Ok. It's okay to tell me I'm wrong. "I'm never wrong," I had a T-shirt that says that, but sometimes I am. 

From what I'm understanding, if I build an OAuth server, I may support PKCE.It depends on the server, but I've seen a lot of them support them optionally. So if the PKCE is passed in, then implement it and use it the second time. What I'm driving at, is if that's the case, then the onus is on the client to say, "Hey, I'm going to implement that PKCE protocol," if that's the right word, "to use that." Does that make sense?

Aaron Parecki: Yes, that makes sense. Just a couple things to clarify there.

Eric Johnson: Ok.

Aaron Parecki: An OAuth server that supports public clients, like mobile apps and single-page apps, should always support PKCE. There's no good reason not to. So if they are letting public clients not use PKCE, that's definitely bad.

Eric Johnson: Ok. So it should be enforced...not just support PKCE, but enforce it?

Aaron: You should enforce it. Now for confidential clients, there are a lot that don't require PKCE or even don't support it. 

Eric Johnson: I'm going to interrupt you one second. For what kind of client did you say that?

Aaron Parecki: For confidential clients.

Eric Johnson: Ok.

Aaron Parecki: I've definitely seen OAuth servers that don't require PKCE or don't even support it. Now this is more recent guidance coming out of the OAuth group, but it turns out PKCE is actually important there, as well.

Eric Johnson: Ok.

Aaron Parecki: The attack that prevents it is too intricate to get into here, but there are videos on the Okta Developer YouTube channel if you're curious about diving into the nitty-gritty on that. But what it effectively means is that PKCE is a good idea even if you do have a client secret because it encapsulates and binds that one request end to end. It protects the flow even for confidential clients. Which effectively means all clients should just do it all the time.

But the point about whether the client is enforcing it or not, the reason for which PKCE is a great idea for all OAuth services support is the mechanism. The way that the mechanism actually works is that the authorization server gets the opportunity to deny requests that don't use PKCE. Whereas other solutions to these similar problems rely on the client developer to get it right and the OAuth server can't even tell if the client developer is doing it right.Eric: Ok, that makes sense to me. So bottom line, use PKCE, pronounced "piksē". That makes complete sense to me.


Stay tuned for the entire Book Club episode "Understanding the secrets of OAuth 2.0" with Aaron Parecki and Eric Johnson.

The OAuth 2.0 authorization framework has become the industry standard in providing secure access to web APIs. It allows users to grant external applications access to their data, such as profile data, photos, and email, without compromising security. OAuth 2.0 Simplified is a guide to building an OAuth 2.0 server. Through high-level overviews, step-by-step instructions, and real-world examples, you will learn how to take advantage of the OAuth 2.0 framework while building a secure API.

Buy the book
OAuth 2.0

Recent Episodes

Our Books

THE ART OF STRATEGY

Erik Schön

Buy the book

Chaos Engineering: System Resiliency in Practice 1st Edition

Casey Rosenthal

Nora Jones

Buy the book

Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith 1st Edition

Sam Newman

Buy the book

Elm in Action

Richard Feldman

Buy the book