OAuth 2.0 PKCE (pronounced "pixy") [1] is described in <i>RFC 7636: Proof Key for Code Exchange by OAuth Public Clients</i> [2]:<p>> OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy").<p>[1] <a href="https://oauth.net/2/pkce/" rel="nofollow">https://oauth.net/2/pkce/</a><p>[2] <a href="https://tools.ietf.org/html/rfc7636" rel="nofollow">https://tools.ietf.org/html/rfc7636</a>
I really like the pseudo sequence diagram they used. Usually I'd draw all the arrows between the actors, which would end up looking very formal. The cartoon talking bubble with plain language seems much more casual and accessible!
Don't forget if you are using a public client, you need to be concerned not just with the client secret, but also with the access token. Unless the token is sender constrained (via MTLS, DPOP or something similar), <i>anyone</i> who gets it can use it to access whatever resources it grants permission to.<p>While losing a client secret to an attacker is obviously worse, because it allows for repeated grant requests, losing an access token can be bad too.<p>So, be aware of both things when you are running in a client like a browser or mobile application which can't be trusted to keep a secret. You can try to minimize the risk by using a HttpOnly cookie for the browser or secure storage (keychain, etc) on a mobile app, as well as keeping your token lifetimes short.<p>Disclosure: I work for an IDaaS provider.
I'm curious why we are still messing around with all these tokens when we could be using asymmetric encryption, like Apple is using for their AppStore connect API <a href="https://developer.apple.com/documentation/appstoreconnectapi/generating_tokens_for_api_requests" rel="nofollow">https://developer.apple.com/documentation/appstoreconnectapi...</a><p>Just seems fundamentally more secure.