7

I'm working on a native app which will use OAuth to allow the user to sign in (or access material itself) to another website. I know I'll be making use of the implicit flow or authorization code flow for OAuth, however all my research regarding security seems to relate to the client secret.

It seems to be the client id for my app (which is provided by the 3rd party site) will be public and therefore exposed. This would allow someone else to take it and, following the same implicit flow, masquerade as my application. Is this just the nature of oauth?

Is there a way of storing this information so it cannot be stolen?

EDIT: I'd just like to clarify - I understand oauth keeps the user's information safe from my app and ideally interceptors. But what is stopping someone from taking my client id (as it is publicly visible through the auth process) and using it for themselves? Are any measures that can be taken defeated by open sourcing the app?

Matt Ke
  • 3,599
  • 12
  • 30
  • 49
Clown
  • 75
  • 1
  • 5
  • Please have a look at [this realated question](https://stackoverflow.com/questions/16321455/what-is-the-difference-between-the-2-workflows-when-to-use-authorization-code-f). If you are using the client id, you will also be using a client secret. The authorization code flow should be used in situations where the client secret will not be exposed to others, e.g. where the "client" (in the sense of OAuth) resides on a web server. – Christian Gawron Jun 10 '18 at 21:18
  • @ChristianGawron, my app that I'm working on is a user facing client without a backend - this is why flows using the client secret won't work for me. "In the implicit flow all data is volatile and there's nothing stored in the app" - this was mentioned in the answer for that post you've provided, would you be able to clarify what is meant by the "data is volatile" and how this would help keep my app's client ID safe? – Clown Jun 10 '18 at 22:01
  • It means that in the implicit flow, no client secret is used - hence you can use this flow in situations like your's where the there is no backend to store the secret in a safe way.. – Christian Gawron Jun 10 '18 at 22:12
  • Yes but where does the client ID start? As a string within my code for example? Within a config file that is parsed by the code? And when the user is directed away for their login process, my client ID is visible in base encoded form isn't it? – Clown Jun 10 '18 at 22:15

1 Answers1

6

The client id can't be protected because it is send as a query parameter in the authorization request.

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

(You could use a web view inside your native app and hide the address bar, but then your app would have access to the user's credentials.)

Further explanations:

  • Using the implicit flow in native apps is not recommended, because an attacker could register your redirect URI at the OS and could catch the callback with the access token.

  • The authorization code flow is a better option. If you are able to store the client secret securely within your app (see link below), an attacker could use your client id to start the authorization or catch the callback, but he wouldn't be able to use the authorization code to get an access token.

Links:

Matt Ke
  • 3,599
  • 12
  • 30
  • 49
  • "an attacker could use your client id to start the authorization or catch the callback" : stated that "redirect_uri" is the uri to where the server must send the authorization code, every redirect_uri must be previously registered at the server side, so how can the bad client get the authorization_code if it is sent to the registered redirect_uri (that is not the uri of the "bad" client ?) – obe6 Apr 13 '20 at 09:09
  • A native app can register any URI at the OS. (At least with Android this is the case. I don't know if this is allowed on iOS.) So, an attacker could register the same URI and catch the callback. (See: https://tools.ietf.org/html/rfc7636#section-1) – Matt Ke Apr 13 '20 at 11:40