5

I'm writing a native application that works against a Google API. Upon registering my application, and despite its explicit designation as Native, the Google Developers Console provides me with a client secret.

As far as I understand the OAuth 2.0 protocol, native apps should never have a client secret, since they cannot guarantee its secrecy. Is Google mistaken in its implementation of OAuth 2.0? How should I proceed?

Dun Peal
  • 16,679
  • 11
  • 33
  • 46

1 Answers1

4

You are correct, the client secret isn't terribly useful in a native application from a being kept secret perspective. I suspect it's there mainly for consistency with the web application flow.

It does however have at least 1 useful feature... the original developer can reset it at any time, effectively revoking all refresh tokens bound to that client ID.

aeijdenberg
  • 2,427
  • 1
  • 16
  • 13
  • 1
    This is my first time working with OAuth so I'm not sure what the security implications are of embedding the client secret in the application. Once I do that, I'm revealing it to the world, and it can be reverse-engineered. How concerned should I be about that? How much of an attack vector does knowing the client secret give a potential attacker? – Dun Peal Dec 13 '13 at 19:26
  • 3
    To get an access token (which is what you ultimately use to access an API) in a native application you need to supply Google with a refresh token (this is what Google provides at the end of the original OAuth dance - and your app typically stores for the user) and your client secret. It is fine to bake this into your application (know it can be reverse engineered) - on it's own it doesn't give access to any data - it is always used with a refresh token. – aeijdenberg Dec 14 '13 at 00:41