OAuth2 Authorisation Code + PKCE Grant Type Walkthrough

[@nt6363]

Thank you for this, great job making the material as clear as possible, much better than other videos I viewed on the topic

[@guesswho2306]

can't find easier explanation than this, Thanks Neil!

[@arunmanglick]

Thank you for wonderful explanation

[@kiranvarghese672]

But with pkce we are preventing csrf attack. However, an intruder app also can create it's own code verifier and request access token is it? How can we prevent an intuder app doing that? Is pkce able to do that?

[@sumitwadhwa8823]

Great explanation. Thanks for sharing.

[@vendetta3953]

so why does this flow even exist if the Access token is eventually to be returned to the Public client(non-secure/frontend channel)? That still makes it possible that the Access token is stolen from the public client?

[@feidongzxzx9109]

Thanks for this great walkthrough.

[@xustuff]

yes, agreed

[@geavenxdd4773]

great content

[@brucardoso2]

Very informative! Thank you Neil

[@subhamthemusicalguy8851]

Awesome video. Thanks a lot

[@altonlebronze3536]

What guarantees that the access token that is eventually returned to the client in the PKCE flow, is not itself intercepted, or worse leaked by the client.

[@barretodavid]

you need to use HTTPS (TLS) for that final POST request so in theory it can't be intercepted

[@ClaudioBarca]

How can access to protected server API resources with read/write/delete authorizations if I have logged-in with a public client (without client-secret) ?

[@premaseemjain]

really helpful. Thanks bro.

[@codedeny6223]

Thank for the detail explanation. Is the application (client) the Front-end (on Browser) ?

[@watherby29]

What's missing I think is why would I do that

[@karldersoose7224]

Thank you

[@bigbtripathi]

What abt client secret ? Does not the app also send the client secret in back channel to authenticate itself?

[@ChaosturnMusic]

as i've understood it, pkce verifies that it's the same client application requesting the initial authorization code that then requests a token in exchange for the code, and that the authorization code hasn't been stolen and injected into a different session. pkce isn't used to *authenticate* the application, it doesn't tell the authorization server the identity of the client application, just that it's the same one for both requests (get code, get token in exchange for code). clients are *authenticated* using a client id and secret, but those can only be considered secured when you have separate front and back channels (like a web app hosted on a server), in that case the client secret only resides on the server which only runs the server code. So these protocols are not mutually exclusive, and they don't fill the same purpose, but pkce becomes more valuable for self-contained apps where you don't have front/back channels and you cannot really trust that a client secret is secure. anyone in the comments feel free to correct me if i'm wrong.

[@РоманБледнов-ъ9и]

I think it is not an HTTP, it is HTTPS, because as u said , there is the TLS

[@olegalekos2181]

smooth

[@HillMick-m8y]

Gonzalez Sandra Martin Joseph Lewis Donna

[@johnfernandes455]

The flow needs to be re-visited... it is terrible

[@AdamFJH]

Yep and still insecure as it is possible for the code verifier to be intercepted...or use something else besides Oauth or come up with your own authentication protocol.

[@ricardodiaz8719]

authorization not authorisation

[@paypal7880]

ClientIds are considered public information. What is stopping a hacker from using some reputed clientId in the PKCE flow and have access to all their scopes?