1

We are writing a pure javascript front-end (in angular) for an API that still uses OAuth 1 for legacy reasons. Being pure javascript means the consumer secret is part of the code that gets downloaded at the start, before authentication, and therefore easily known to an attacker.

This secret is used in calculating the authentication codes together with the token secret, and the token (and the authentication exchange) is protected by TLS and in-browser sandboxing in the same way the bearer token would be if we switched to OAuth 2, which does not encrypt the bearer token at all.

So by revealing the client secret, are we creating any additional attack surface compared to OAuth 2, or is it simply equivalent?

In other words, provided the same methods of protecting the communication and the authorization/access token delivery are used, is there an attack that is viable against OAuth 1 with leaked client secret that is not viable against OAuth 2 with no client secret in SPA mode?

Jan Hudec
  • 531
  • 1
  • 5
  • 10
  • In your specific use case, it's apples and oranges. [oAuth 1 assumes a confidential client](https://stackoverflow.com/questions/4113934/how-is-oauth-2-different-from-oauth-1/35775049#35775049), SPA is a public client. Public clients have been an issue in oAuth2, the "protocol" (quotes intentional) is too loose. oAuth 2.1 is attempting to fix this. – identigral Aug 29 '20 at 17:38
  • @identigral, oauth 1 assumes confidential client, but it also assumes non-confidential communication channel. When it does have a confidential communication channel, the message signatures become superfluous, and then the question is whether the first assumption can be relaxed. – Jan Hudec Aug 29 '20 at 18:57
  • Still not sure what you're after. You can't protect a secret in a public client, it's only a question of attack complexity/cost vs asset value. Phishing/mix-up attacks can defeat message signature with TLS. In oauth2 you can do a number of things to mitigate...and these things have been published in 2.1. Perhaps have a look at those and adapt them to your oauth1 implementation. – identigral Aug 29 '20 at 19:56
  • @identigral, is there any attack that is viable against oauth 1 with leaked client secret that is not viable against oauth 2 with simple bearer tokens and no client secret at all given that the communication channel and access token delivery are are protected by the same measures or not? (except the redirect hijack, which is fairly complicated for what can be more easily achieved by persuading the user to install a malicious browser plugin that can trivially pick the token from the local storage). – Jan Hudec Aug 29 '20 at 20:26

1 Answers1

0

Basically you are leaking the secret... so it's no longer a secret.

With oAuth 2 you have the option of not using a static key by implementing PKCE in your flow. That means you can get the best of both worlds: easy login and secured secrets.

A big difference between oAuth 1 and oAuth 2 is that with oAuth2 you dependent on the browser's implementation of crypto, while for oAuth1 you need to bring your own.

This all means that unless you have additional security measures in place, and since you leak the secret, your application is not safe from abuse and eavesdropping, therefor I would go with a switch over to oAuth 2 with PKCE.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
LvB
  • 8,217
  • 1
  • 26
  • 43
  • I did specify the control in place – it relies on the browser crypto and origin separation. The application is protected from abuse and eavesdropping by that (by the way, it is the *only* thing that protects it from *eavesdropping*). – Jan Hudec Aug 20 '20 at 10:51
  • I also don't see any benefit of PKCE for the use-case at all. PKCE protects from interception of the redirect, but in-browser that is no simpler than inspecting the application itself, so it does not prevent any attack vector. – Jan Hudec Aug 20 '20 at 10:57
  • PKCE also protects against replay attacks. – LvB Aug 20 '20 at 10:59
  • If the attacker can replay the communication inside the TLS, they already own the application. And the TLS session itself is already protected. So what replay attacks are you speaking about? – Jan Hudec Aug 20 '20 at 12:21
  • how does that protect against an attacker just reading out the secret and the url's form the end result (the one pager). you can reply alot with just teh URL's (which is often easier to get than access to teh TLS session itself..... ) – LvB Aug 20 '20 at 14:45
  • Post does not shield the url. Often browser can be tricked into doing a get instead of a post. Also is there any reason you can trust the endpoint? – LvB Aug 20 '20 at 14:55
  • Post does not shield the URL, but in that case the URL does not contain the exploitable information. Being able to trick the browser to do get instead requires owning it already. The endpoint certificate has been verified, so it can be trusted. OAuth 2 requires that too. – Jan Hudec Aug 20 '20 at 15:04