6 ms·

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

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.

deng 6y ago
> 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)?
- tptacek 6y ago
  Google Mail's OAuth2 instructions discuss this point explicitly.
  - diafygi 6y ago
    Have a link?
    - psanford 6y ago
      "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 https://developers.google.com/identity/protocols/oauth2
- dwaite 6y ago
  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 https://github.com/openid/AppAuth-JS/issues/46
  - deng 6y ago
    The Google engineer should read Google's terms of service which explicitly states that you may not do that (see my reply above).
- niftich 6y ago
  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/native-app https://developers.google.com/identity/protocols/oauth2/nati... [2] https://web.archive.org/web/20150520223809/https://developers.google.com/identity/protocols/OAuth2InstalledApp https://web.archive.org/web/20150520223809/https://developer...
  - deng 6y ago
    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 https://developers.google.com/terms
mooreds 6y ago
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-oauth-in-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.)
- tptacek 6y ago
  People build SPAs with the OAuth2 code flow (and PKCE) all the time.
  - mooreds 6y ago
    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.
    - thecopy 6y ago
      No, with PKCE you can do auth code from an SPA
      - mooreds 6y ago
        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 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?
        krooj 6y ago

deng 6y ago

> 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)?

tptacek 6y ago
Google Mail's OAuth2 instructions discuss this point explicitly.
- diafygi 6y ago
  Have a link?
  - psanford 6y ago
    "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 https://developers.google.com/identity/protocols/oauth2
dwaite 6y ago
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 https://github.com/openid/AppAuth-JS/issues/46
- deng 6y ago
  The Google engineer should read Google's terms of service which explicitly states that you may not do that (see my reply above).
niftich 6y ago
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/native-app https://developers.google.com/identity/protocols/oauth2/nati... [2] https://web.archive.org/web/20150520223809/https://developers.google.com/identity/protocols/OAuth2InstalledApp https://web.archive.org/web/20150520223809/https://developer...
- deng 6y ago
  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 https://developers.google.com/terms

mooreds 6y ago

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-oauth-in-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.)

tptacek 6y ago
People build SPAs with the OAuth2 code flow (and PKCE) all the time.
- mooreds 6y ago
  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.
  - thecopy 6y ago
    No, with PKCE you can do auth code from an SPA
    - mooreds 6y ago
      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 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?
      - krooj 6y ago