0

I was going through auth 2.0 protocol [1], along with the proof key RFC [2]. It explains well as to how the protocol protects against malicious apps listening to network traffic. However, I'm unable to understand how the auth 2.0 protocol protects against malicious code working on the browser itself.

Let's take a simple case of the proof key RFC protocol. We generate a high-entropy code verifier, but we have to store it somewhere in the browser (possibly in cookies/browser's local storage) to use it again to get the token. Now, in case there is malicious code executing on the browser, it can always access the cookies/local storage and get the code verifier.

Is there a protocol enhancement (similar to RFC-7636) that protects against cookie based exploits? If not, how do we mitigate it?

[1] https://www.rfc-editor.org/rfc/rfc6749

[2] https://www.rfc-editor.org/rfc/rfc7636

Community
  • 1
  • 1
Hrishi
  • 103
  • 1
  • 6

1 Answers1

1

OAuth 2.0 caters for different types of Clients i.e. Web Clients, In-Browser Clients and Native Mobile App Clients.

The PCKE OAuth 2.0 mechanism was primarily designed for Native Mobile Apps. It allows public clients to protect themselves against malicious apps and attackers that may get hold of the Authorization Code.

When dealing with Web Clients, the PCKE mechanism is not needed since these attacks can be prevented by the use of a confidential client with a client secret stored server-side.

When dealing with In-Browser Clients there's the problem that you mention but in general all hope is lost when malicious code is running in the browser.

In summary: PKCE is not a mechanism to defend against cross site scripting attacks in browsers.

Hans Z.
  • 50,496
  • 12
  • 102
  • 115