OAuth PKCE | OAuth Proof Key for Code Exchange explained

[@jgoebel]

Bottom line: always use PKCE with OAuth 2. Was the explanation on how PKCE works clear? Let me know in the comments below.

[@PnBTravloggers]

It was perfectly explained. Thank you!

[@jessetwumboafo]

This was a great explanation of PKCE! Thank you! The only part that wasn't clear to me is where the code verifier gets stored? Especially in mobile apps? If I understand correctly, the reason we use PKCE is because we have a public client where we cannot guarantee safe storage of the client secret. How then can we guarantee safe storage of the code verifier (even if it's for a short while)?

[@sajinrk]

After a long search, this is a clear and simple explanation. Thanks!

[@madoudev2277]

Crystal clear !

[@TeaObvious]

loved the explanation, thank you!

[@-indeed8285]

Understood so well. summary: Generate a string, hash it, send the hash in first request with hash method, in later request send the string to verify it is you who send the first request. Nice.

[@jgoebel]

that about sums it up

[@Stan-l-e-y]

Thank you! This was the only video on youtube about OAuth PKCE that actually made sense, even the facebook for developers guide doesnt come close to this level of explanation

[@craigstadlock]

This video is missing the entire point which is the fundamental difference between the client secret and the PKCE code. The client secret is static so it must be stored in source which results in it being in the compiled code and subject to discovery via decomplication. The PKCE code is not static and needs to be generated at runtime and stored in the app's memory (not source). Becuase its in memory and apps usually* run in isolated environments another app is unable to read the value of the the PKCE code. If the client implements PKCE wrong and does not generate the PKCE code everytime but uses a static value in code then it is equally as insecure as using a client secret. One issue is with with any app environment in which one app can read the memory of another app... like most desktop apps (Windows, ...). There you would need to use something like a "secure string".

[@Dani-bj8zk]

thank you man! that was the exact same doubt I had, thank you for the clarification

[@alastairtheduke]

This point was actually made pretty clear to me by the video.

[@centerfield6339]

The client secret does not need to be stored in source code. It should be config. It should be only used in environments that can store that configuration securely, like a server you control.

[@Tobias42]

Excellent explanation! Made everything crystal clear, after having read some confusing blog posts before.

[@jgoebel]

Thx, I'm glad it was helpful

[@ChrisWork-e6l]

Really simply explained. Seen some much more complex explanations of something that is really pretty staright-forward.

[@dominiks5318]

I saw 2 Oauth courses on Udemy but yours (free) has the best explanations. Thanks.

[@FellTheSky]

since you are really good at explaining I would like to suggest a video on multi tenant vs single tenant apps. Your session vs token was very helpful !

[@jgoebel]

thx, will add it to my list of potential topics 👍

[@zmxn007]

Short but a Beautiful explanation of PKCE with OAuth. Thanks

[@Harika-r5e]

the explanation was very clear up to the point.

[@jgoebel]

thx

[@viktorbranco8362]

the only video on PKCE I managed to understand. Subscribed!

[@vivekweb2013]

Great explanation. Thanks a lot. I just have one question - since the clientId is sent by the app and its not a secret, what if the attacker captures and uses my client-id? Since in this case google can not verify that the flow is triggered by an actual client's app. Does google authenticate user by showing my client id in this scenario?

[@Baheerathan1990]

I think Google shows the App name which requests the access in the authentication UI

[@barani7821]

Best explanation for PKCE, Thanks so much

[@TheAkiller101]

best explanation of pkce on the internet !

[@jgoebel]

thx zeid

[@fineline392]

Thank you so much for the great explanation!

[@puredjoko]

Very nice explanation! Keep up the good work!

[@jgoebel]

thx puredjoko

[@IsSheRG710]

Thank you for explaining this clearly and showing how it looks in the browser. Really helps us visual and process oriented ppl!

[@jgoebel]

Glad it was helpful!

[@manideepkumar959]

this is perfectly clear and i understood , i have the below doubt, all this concept is to prevent auth code theft, but what if the end auth token itself is theft ? how to solve that problem

[@k.deepak]

I have a question: when we call the token endpoint, we also pass it the client secret. So, how can a malicious application obtain my client secret?

[@jgoebel]

PKCE was designed to fix the attack vector explained in the video on mobile application (intercepting auth codes by registering the same URL like some other app). Unless you use dynamic client registration for mobile apps, mobile apps are public clients. You would not ship a client secret in it because this can be easily extracted from the app itself. These days, the recommendation is to use PKCE for every type of client (also web). The original OAuth spec has the state parameter that was originally designed to prevent CSRF (which PKCE does as well). The state parameter can now be used for sth. different. PKCE is also better because it sends over the hash of a high entropy random string instead of the random string itself

[@Smaugthur]

EXPLAINED WOUNDERFULLY! THANKS A LOT!

[@jgoebel]

Glad you liked it!

[@carlotadias9335]

Thank you ! For me I understand the principle (listening at 0.75 speed) but I don't see why the attacker cannot intercept a normal request to the resource server where the access token and the original PKCE are sent, and intercept and get the PKCE code (original) there. With that, it can then itself request authentication (an auth token), for example he can intercept both authentication and authorization requests to get the mix of parameters he needs to act on behalf of the user. Isn't this possible?

[@ishanmahajan7264]

Well explained, have gone through a couple of videos before your's but your's explained well

[@jgoebel]

great

[@felixhaberle9522]

Bester Mann, hat mir sehr zum Verständnis geholfen!!

[@jgoebel]

gerne 👍

[@madoudev2277]

Great explanation, thanks ! I was wondering what would happen if the malicious app also stole the code that generates the pkce hash since this code may also be exposed in the front channel... ? Could you comment on that please ?

[@jeno101]

I too have the same doubt.. Did you got the answer to it ?

[@TuanNguyen-ed9rb]

@@jeno101 The code that generates the pkce hash is the public hash method (SHA256 for example), and this method is included in the URL, so there's nothing to hide here related to the hash method. I don't see a problem with the hash method used to generate the code_challenge.

[@codezard1]

I have a question, while redirecting at very first time to Athorization server, we pass code challenge and the method with which it is hashed, if anyone steals that information then it can easily decrypt the original Code verifier and next time it can steal the Authorization Code and send the same code verifier string.

[@jgoebel]

The code verifier is a randomly generated, high-entropy string that is generated freshly for every OAuth authorization

[@alexandershein4657]

Thank you for your effort! PKCE is well explained.

[@jgoebel]

thx

[@nhefner]

fantastic explanation, thank you!!

[@yutikavathia1469]

Thanks for the explanation. How to restrict mailbox access when using PKCE to read emails?

[@MartinGonzalez-xp5yr]

Excelente explicación, precisa y clara. Gracias!

[@navi802]

Thanks for an amazing series. I loved it. Just one question, If someone can intercept secret than they can also intercept PKCE, isn't it? I understand first time one send the hash but next time its the actual text and if someone can intercept multiple request the this is not a full proof solution. What is your thoughts on this?

[@jgoebel]

on mobile phones apps run in isolated containers. In addition, the REST call is with https, so the clear text secret is protected

[@Dani-bj8zk]

hi, I think the main difference here is that the PKCE is sent via a POST request: this makes it harder to intercept than the authorization_code (which is sent back in the redirect URL from authz server to the client app) for malicious apps

[@psaunder1975]

Thanks for a very clear explanation, your diagram was very helpful. :)

[@bogdanbogdan513]

hey man, great work in explaining this, I was just wondering if there's any chance you made these draws public somewhere, thanks!

[@michaeld5899]

What is the recommended way for proper logout in PKCE?

[@jgoebel]

Hi Michael, I recently published a video about token revocation with OAuth 2. PKCE is just and additional security mechanism that you use to obtain the token. It does not influence how you revoke a token

[@sriki12345678]

@@jgoebel can you please attach the video link here for a quick reference?

[@jgoebel]

@@sriki12345678 kzbin.info/www/bejne/f37MhHeGi7yrrZI

[@oleksandrdiachuk2978]

Nice and clear. Thank you!

[@jgoebel]

Glad it was helpful!

[@great_cosmic_pig]

Excellent explanation, thank you.

[@jgoebel]

Glad it was helpful!

[@alastairtheduke]

Is it possible for an attacker to see the hash on the way to the authorization server and also the code verifier (the plain text) on the way back to authorization server thus giving the attacker everything they need? I'm assuming this would be hard since using https everything should be encrypted, but theoretically is this possible?

[@jgoebel]

Yes indeed. The reason that a hash of a high entropy string is sent over is because that even if an attacker sees what you send to the server, they will not be able to get the code verifier. Of course if an attacker can intercept the code verifier (i.e. intercept the TLS connection), then he can impersonate you. However, this basically means that an attacker has full cross site scripting access. Therefore having a Content Security Policy that prevennts XSS is very imporant. Once you have an XSS vulnerability you are screwed in general.

[@alimorgaan1329]

well explained, thank you!

[@nourayat]

is this for mobile only ? cant use the PKCE concept in Browser ?

[@jgoebel]

PKCE was originally designed because of the challenges that occured in mobile applications. Today the recommendation is to always use PKCE.

[@BL0WUPFISH]

Is there anymore information regarding PKCE + confidential client? It seems as if it’s a new specification and there is a lack of information. I’ll check the RFC

[@jgoebel]

Hi Blo0wupfish, there is a recommendation in the OAuth current security best practices to always use PKCE also for confidentical clients: "Clients MUST prevent injection (replay) of authorization codes into the authorization response by attackers. Public clients MUST use PKCE [RFC7636] to this end. For confidential clients, the use of PKCE [RFC7636] is RECOMMENDED. " " Note: Although PKCE was designed as a mechanism to protect native apps, this advice applies to all kinds of OAuth clients, including web applications." datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-2.1.1

[@KarlChow]

Great vid. Keep it up!

[@jgoebel]

Thanks!

[@piotrwolski4742]

Hey, Should i ditch client secret all together now and only use client Id and code challenge? Or can i use everything like before and add code challenge on top of it? Also do i have to still use nonce with pkce?

[@jgoebel]

Hi Pitr, PKCE is an extension that you use on top of the authorization code grant. I.e. you still have a client id and client secret (client secret only if you have a confidential client) and you have an additional query parameter in your redirect URL and an additional parameter when exchanging the authorization code for a token. nonce is afaik from OpenID Connect, not from OAuth

[@piotrwolski4742]

@@jgoebel Thank you, your video was the best out of many i checked for that topic. So keep up the good work. Cheers

[@jgoebel]

@@piotrwolski4742 thx

[@mansurmaratov8133]

cool! thank you for video

[@jgoebel]

you're welcome Mansur 👍

[@RAZUMOVSKY228]

Hej prod, great vids and explanation about OAuth + PKCE, I saw both :) Liked + subed However, could you share your auth diagrams you used in videos? Obviously in read only mode, thanks

[@jacekbiaecki8076]

Is the mobile app depicted twice on the diagram? 1) mobile app with "Sign-in with Google" button 2) the SAME mobile app receiving authorization code and doing the whole "back channel" exchange?

[@anotherrohit]

The sign in with google was symbolic to represent the user agent for public client and differentiates from authorization server of google.

[@bohdanzhylavskyi7341]

thanks

[@jgoebel]

You're welcome!

[@blipintime1543]

That malicious app should also steal the client credentials and use them in combination of authorization code to exchange access token. Worth mention this point while highlighting the problem with OAuth2.1 Client role. These days bundling the clients with client id and secret cant guarantee it's secrecy.

[@RobertNealy-g2n]

Howe Stravenue

[@JoeCharron-c4g]

Jacobi Ridge

[@PaulDobos-q8w]

Kaia Street

[@HalKim-u8i]

Dolores Prairie

[@ChristopherHogle-c9x]

Shanon Dam

[@BradleyGoggins-r5l]

Mylene Springs

[@SharonPerez-m8f]

Wallace Extension

[@سليمانسليمان-و4ف]

Adams Lodge

[@LloydZebulon-n5m]

Rippin Harbor

[@HaydnKevin-h3n]

Shane Ford

[@EricaLassiter-y8o]

Upton Brook

[@TonishaLee-n9q]

Norris Forges

[@WesleyBelinda-v6j]

Haylie Extensions

[@AshleySaltzman-k4x]

Samantha Circles

[@DortheaGoethe-j4n]

Wilkinson Meadow

[@NeedhamClarence-l5g]

Smith Street

[@DougStrei-h9n]

Braun Glens

[@WilliamOcampo-k5h]

Gennaro Radial

[@LynnBraaten-l4m]

Abelardo Keys

[@PrestonBonnifield-j6s]

Bashirian Haven

[@RoseRames-w9o]

Bins Radial

[@JodySullivan-v2q]

Daphney Orchard

[@LiDaoud-z9j]

Lila Curve

[@NigelMcentire-t9v]

Jovanny Prairie

[@SnowChrist-u6d]

Hauck Shores

[@ChristopherMoore-j2j]

Lauryn Grove

[@PansyAdam-f9n]

Ofelia Coves

[@PerkinHoney-v4q]

Bradtke Spring

[@PaulYoung-r3z]

Malinda Bridge

[@HertyRoderick-y5o]

Gleason Lake

[@TrollpoeArmstrong-t9y]

Mills Corner

[@NobleAmbrosone-d3h]

Phoebe Fields

[@JobGustave-n7n]

Jacobi Plaza

[@ChanceFord-o7r]

Sienna Shoals

[@PhilemonVic-o5i]

Malika Common

[@BroadWebb-r6w]

Joshuah Cliffs

[@MarkHarlan-n8i]

Rutherford Divide

[@JessAchilles-b3s]

Miller Groves

[@fhghghhjgh-h4k]

Medhurst Shores

[@AlyUrsula-v4i]

Delfina Crest

[@EdwardMeek-e7c]

Arturo Meadow

[@SoutheyEdmund-q2m]

Mortimer Locks

[@EmilyTracy-c2j]

Morar Place

[@JamesEgbert-u4u]

Smith Way

[@LawCarey-t5x]

Sigrid Mountain

[@JanelleWong-v6x]

Cade Glen

[@MorrisGreen-g8n]

Joey Avenue

[@JudsonTruda-x4o]

Dayna Locks

[@KelvinDoyle-f6r]

Ledner Plain

[@PaulCampbell-y7v]

Tamia Plains

[@JohnathanChandler-d6v]

Claude Village

[@MarcOsborne-f8s]

Boyer Brooks

[@husc-c7y]

Johnson Rue

[@EleanorBloomer-x9w]

Nigel Centers