Hacker News Reader

Comment by nicolaslem | Hacker News Reader

From my understanding the best practice for applications that run on clients' machines (Javascript SPA, mobile app, email client) is to not use a client secret at all. Just use a client id and assume that anyone can reuse it.

Of course that is if the OAuth provider allows it.

View on HN

Yup, a SPA can't really keep a secret, right?

That's why the best option is to set up a secure middleware layer to hold your secrets. Here's an example using react: https://fusionauth.io/blog/2020/03/10/securely-implement-oau...

(Full disclosure, this is a post on the blog of the companyfor which I work.)

People build SPAs with the OAuth2 code flow (and PKCE) all the time.

Sorry, I misspoke. Those SPAs always have middleware to handle the authorization code, right?

It's really the implicit grant (where access tokens are available to the client) that should be avoided.

No, with PKCE you can do auth code from an SPA

With the implicit grant? I read the RFC recently and thought it was only for the Authorization Code grant.

From https://tools.ietf.org/html/rfc7636

"OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy")."

At the end of the day, no matter what the grant, if you store the access tokens (or refresh tokens) in the browser running an SPA, it is vulnerable to an XSS attack, right?

With PKCE you can use the authorzation_code grant flow. The whole issue with SPAs and the authorization_code grant flow isn't the presence or absence of middleware; rather, it's the lack of a confidential client. PKCE gets around the requirement for a client to securely store it's secret.

Right, but even after the authorization code flow, the access token is stored somewhere on the client.

My understanding is that that is suboptimal because the browser has such a large surface area to secure.

This is solvable by use of a web worker as a key vault:

https://gitlab.com/jimdigriz/oauth2-worker

That is very cool, thanks for sharing!

Edit: This seems pretty new, any timeline for a release?

Thanks. I am not wholly convinced of the benefits of releases for a project of this scale, I suspect most will just reimplement the moving parts in their own code for a variety of (usually NIH) reasons.

> Of course that is if the OAuth provider allows it.

That's the catch. Last time I checked, at least Google didn't. So how can you write a (F)OSS email application for accessing GMail via OAuth2, without putting the secrets into the code (which Google also forbids)?

Google Mail's OAuth2 instructions discuss this point explicitly.

Have a link?

"The process results in a client ID and, in some cases, a client secret, which you embed in the source code of your application. (In this context, the client secret is obviously not treated as a secret.)"[0]

[0]: https://developers.google.com/identity/protocols/oauth2

The conversation I had with a Google engineer implied the appropriate course of action was to embed the secret.

https://github.com/openid/AppAuth-JS/issues/46

The Google engineer should read Google's terms of service which explicitly states that you may not do that (see my reply above).

In this situation, their guidance says to embed the secret, because in this context it's obviously not a secret. Here's the current page [1]; here's the earliest Archive.org snapshot of its one-earlier predecessor page from 2015 [2] -- the advice has been consistent.

[1] https://developers.google.com/identity/protocols/oauth2/nati... [2] https://web.archive.org/web/20150520223809/https://developer...

No, Google is not consistent in the slightest, because their terms of service directly contradict this statement:

"Developer credentials (such as passwords, keys, and client IDs) are intended to be used by you and identify your API Client. You will keep your credentials confidential and make reasonable efforts to prevent and discourage other API Clients from using your credentials. Developer credentials may not be embedded in open source projects."

From: https://developers.google.com/terms

Reply on news.ycombinator.com