2

Yohoho! I am building an application that leverages OAuth to pull user data from provider APIs, and am wondering about the RFC compliance of the flow I have chosen.

Currently, the user signs into the authorization server which sends an auth code to my frontend client. The frontend then passes the auth code to my backend, which exchanges it for an auth token and then makes calls to the provider to pull data.

In this best practices document, it states:

Note: although PKCE so far was recommended as a mechanism to protect native apps, this advice applies to all kinds of OAuth clients, including web applications.

To my understanding, PKCE is designed to ensure the token is granted to the same entity that requested the auth code, in order to prevent attackers from using stolen auth codes to execute unwarranted requests.

Now, it makes sense to me why this is important even if the backend keeps the client secret unexposed, since the attacker can make requests to the backend with the intercepted auth code to receive the token. However in my flow, since I am not creating an authentication scheme and rather trying to authorize premeditated requests, the token stays with the backend.

So why is PKCE recommended here? It seems to me the most a stolen auth code can do is initiate an API request from the backend, with no token or data being returned to the attacker. And assuming a PKCE implementation is the way to go, how exactly would it work? The frontend requesting the auth code and the backend trading it for a token aren't exactly the same, so would it be as simple as passing the code_verifier to the backend to make the call?

Some clarification would be greatly appreciated.

Nathan
  • 23
  • 4

1 Answers1

3

PKCE ensures that the party who started the login is also completing it, and there are two main variations that I'll summarise below in terms of Single Page Apps (SPA).

PUBLIC CLIENTS

Consider a Single Page App that runs a code flow implemented only in Javascript. This would store a code verifier in session storage during the OpenID Connect redirect. Upon return to the app after login, this would be sent, along with the authorization code and state to the Authorization Server.

This would return tokens to the browser. If there was a Cross Site Scripting vulnerability, the flow could be abused. In particular the malicious code could spin up a hidden iframe and use prompt=none to get tokens silently.

CONFIDENTIAL CLIENTS

Therefore the current best practice for Single Page Apps is to use a Backend for Frontend (BFF), and never return tokens to the browser. In this model it is more natural for the BFF to operate like a traditional OpenID Connect website, where both the state and code_verifier are stored in a login cookie that lasts for the duration of the sign-in process.

If there was a Cross Site Scripting vulnerability, then session riding is possible by the malicious code, to send the authorization code to the BFF and complete a login. However, this would just result in writing secure cookies that the browser cannot access. Similarly, the hidden iframe hack would also only rewrite cookies.

The code_verifier could alternatively be stored in session storage and sent from the browser to the BFF, but it would be easy enough for malicious code to grab it and also send it to the server. This does not really change the risks, and the key point is that no tokens should be returned to the browser. It is OK to use secondary security values in the browser, as long as you can justify them, eg for security reviewers. Generally though it is easier to explain if secure values are in secure cookies and less visible to Javascript.

FURTHER INFO

Best practices often vary depending on the customer use case, and at Curity we provide resources for customers (and general readers) to explain secure design patterns. These are based on security standards and we translate them to customer use cases. You may find our recent SPA Security Whitepaper useful.

Gary Archer
  • 22,534
  • 2
  • 12
  • 24
  • Thanks for the reply. It seems the accepted answer of this question: https://stackoverflow.com/questions/61999232/oauth2-pkce-who-should-generate-code-verifier-and-code-challenge?rq=1 is saying the opposite? They are suggesting generating the PKCE values in the frontend and then passing it to the backend alongside the auth code, because it "protects backend to frontend communication" while generating it in the backend as you suggested doesn't? Am I misunderstanding some part of the flow? – Nathan Mar 17 '22 at 22:53
  • Good question - I think the best way to think of it is in terms of threats, so I've clarified my answer above in these terms. – Gary Archer Mar 18 '22 at 08:16
  • Fantastic answer, thank you! It makes sense to try to keep the values as far away from the browser as possible, even if not explicitly necessary. I'll be following your approach. – Nathan Mar 18 '22 at 18:51
  • Sorry one last question, why store the state and code_verifier in a cookie rather than keeping it as a variable in the server? It seems to me that in the flow you described, the frontend doesn't need to access them since the access token is requested on the backend, and the code_challenge is being sent anyways through the provider url as a query parameter. – Nathan Mar 18 '22 at 22:31
  • The cookie strengthens the call to the BFF's EndLogin endpoint. Also, cookies enables the BFF to be stateless and easier to manage. – Gary Archer Mar 19 '22 at 06:46