In the OAuth2 authorization code grant, in the case of a public client, what is the point of exchanging the authorization code for a token, rather than issuing a token directly?
2 Answers
The authorization code is handed over to the client in the front-channel and thus known by the user and everyone knowing the URI with the code (browser addons, server logs).
Exchanging the code for an access token (and depending on the use case also a refresh token) is done in the back-channel and thus allows the client to fetch the tokens in the backend and hide the tokens from the user.
The extra step also allows the authorization server to identify the client before issuing the tokens via the client’s credentials or via PKCE (defined by RFC 7636).
By ommitting the extra step with exchanging the code you basically throw a key over a wall and hope for the right person to catch it...
- Thanks, but I'm talking about public clients. In my understanding this means there is no back-channel.Mr. B– Mr. B2024-12-07 14:56:06 +00:00Commented Dec 7, 2024 at 14:56
- @Mr.B The token endpoint is back-channel communication, although the implementation might call the endpoint in code under control of the user. Public clients can also proof to the authorization server that they initiated the authorization request by using PKCE, although a client cannot proof its identity as client. Without the extra step, PKCE won’t work.JuliusPC– JuliusPC2024-12-07 23:06:54 +00:00Commented Dec 7, 2024 at 23:06
- Perhaps the language should be "the public client does not have one or more required API parameters to request the token". Such as a ... secret. Otherwise I would stick with "This ensures that the request to get the access token is made only from the application, and not from a potential attacker that may have intercepted the authorization code."Greg Askew– Greg Askew2024-12-08 11:14:05 +00:00Commented Dec 8, 2024 at 11:14
- Preventing authorisation code leakage
If the authorization code is intercepted during transmission (e.g. via a malicious app or a network attack), the attacker would still need to execute the exchange process with the authorization server. In the case of confidential clients, this exchange requires a client secret; for public clients, the attacker would still need to exploit a valid redirect URI, which is typically protected by PKCE. Which leads me to the next reason:
- Support for PKCE
Proof Key for Code Exchange (PKCE) adds an additional layer of security by requiring the public client to include a code challenge during the initial authorization request and then a matching code verifier during the token exchange. This makes sure that the client that initiated the request is the same client completing the token exchange, essentially stopping code injection or interception attacks.
For more information, you can read Oauth’s official documentation on PKCE in Oauth2.
