6

Using most OAuth 2.0 flows, a client application can identify itself to the authorization server by means of a "client id" and "client secret."

The OAuth 2 specification says that the client secret should indeed be kept secret.

However, if the client secret is inside of the application, then it's not secret - someone can use a debugger, disassembler, etc to view it.

So I am not sure the effectiveness and/or purpose of this client secret. Furthermore, are there any recommendations for securing a client secret on a client under the control of the general populace? The purpose here is to establish some form of trust between the client application and the Authorization server, independent of the resource owner (user).

Finally, what is the difference between using an OAuth flow without a client secret vs. using one with a client secret and not keeping that "client secret" actually secret?

the_endian
  • 1,009
  • 1
  • 8
  • 17
  • Can you share the reference to where the standard says the client secret should be secret? I could not see that but I may have been looking in the wrong RFC. Google's docs https://developers.google.com/identity/protocols/OAuth2#libraries say that a client can't keep secrets therefore that when you generate your client ID you sometimes get a secret and sometimes do not. This is correct: you don't get a secret if you select IOS but you do get a secret if it's type Other. I am now curious why Google are not implementing what the standard says. – Unicorn Tears Aug 10 '19 at 12:09
  • @UnicornTears https://tools.ietf.org/html/rfc6819#section-4.1.1 – the_endian Aug 10 '19 at 19:50

2 Answers2

4

OAuth2 specification defines two types of clients

   confidential
      Clients capable of maintaining the confidentiality of their
      credentials (e.g., client implemented on a secure server with
      restricted access to the client credentials), or capable of secure
      client authentication using other means.

   public
      Clients incapable of maintaining the confidentiality of their
      credentials (e.g., clients executing on the device used by the
      resource owner, such as an installed native application or a web
      browser-based application), and incapable of secure client
      authentication via any other means.

And the use client secret are applicable only to confidential clients.

So basically You use it only when it can reside safely on secure server - and not in case of rich client (desktop, mobile, javascript in browser).

The purpose of the client secret is to prevent impersonation of the client. As you noticed without it anyone can extract credentials from end user application and perform OAuth flows on his own. But if the secret is safe server side - then one can not complete flow and obtain token.

As for using client secrets in client under the control of the general populace my recommendation is to don't use it at all as it adds nothing in terms of security.

Community
  • 1
AGrzes
  • 526
  • 4
  • 10
1

If the client is public and unable to keep the client secret then it should use PKCE instead. quoting from the guide:

The authorization server can require that public clients must use the PKCE extension. This is really the only way to allow public clients to have a secure authorization flow without using the client secret. Since the authorization server should know that a specific client ID corresponds to a public client, it can deny authorization requests for public clients that do not contain a code challenge.

raven
  • 121
  • 1
  • 4