Protocols
PKCE
Proof Key for Code Exchange — binds an authorization code to the client that requested it, so a stolen code is useless.
What PKCE means
PKCE stops an intercepted authorization code from being redeemed by anyone other than the client that started the flow. The client generates a random secret, sends its hash when it begins, and presents the original secret when it exchanges the code. Without the secret, the code cannot be used.
Defined in: RFC 7636.
How it works
It was introduced for mobile applications, where a redirect could be intercepted by another app registered for the same URI scheme and where no client secret can be kept confidential anyway. It is now recommended for every authorization code flow, including confidential server-side clients, because the cost is negligible and it closes the interception path regardless of client type.
The mechanism is deliberately simple: generate a high-entropy `code_verifier`, send `code_challenge = SHA-256(code_verifier)` with the authorization request, and send the raw verifier with the token request. The server compares. An attacker who captures the code has the hash, not the verifier, and cannot reverse one into the other.
Use the S256 challenge method. The `plain` method sends the verifier itself as the challenge, which provides no protection against anyone who can see the authorization request — the exact attacker PKCE exists to stop.
The mistake people actually make
Generating the verifier without a cryptographic random source. A verifier from a predictable pseudo-random generator is guessable, and PKCE then provides the appearance of protection with none of the substance.
In Authreads
How this applies here
PKCE is used for the authorization code exchange on both integration paths.
Every capability is listed on /roadmap as Available, In progress or Planned. Nothing is described as available here that is not listed as Available there.
Guides that go deeper
Related terms
OAuth 2.0
An authorization framework that lets an application obtain limited access to a resource without handling the user's credentials.
OpenID Connect (OIDC)
An identity layer on top of OAuth 2.0 that lets an application verify who a user is, not just what it may access.
Authorization code flow
The OAuth 2.0 flow where the browser receives a short-lived code that the application exchanges for tokens from its server.
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.