0

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?

4
  • In your specific use case, it's apples and oranges. oAuth 1 assumes a confidential client, 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
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.

7
  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.