Secure OAuth 2 flow for client-side or mobile app

Question

I'm implementing an API and a client-side web app, and they are supposed to communicate via an API and use OAuth 2 for authentication.

I can't get over my confusion on what's the right way to authenticate users (i.e. without major security oversights).

I gathered the following:

• Ideally, you should expose a web form on the API server which takes username and password and redirects back with an authorisation code, to be exchanged client-side for an access token access token.
• The approach I described is considered cumbersome, so OAuth 2 offers an implicit flow where the client-side app makes a request containing a client_id and the user's credentials, which it gathers. It receives an access token.
• Authentication toolkits seem to be wary of allowing only the client_id to be passed, and instead require the client_secret to be included.
• Based on the previous point, as a developer you may have to embed your client_secret in the distributable application, thus making it public.
• Some peers with an understanding of OAuth 2 told me that it is not uncommon for developers to embed the client_secret in their distributables, and that some high-profile services (allegedly Twitter) do it as well.
• If you add a proxy between the client and the OAuth 2 server to add the client_secret to requests, it doesn't improve security as it is similar to ignoring the client_secret altogether.
• The only security concern that I could find related to embedding client_id and client_secret in the client is that an attacker may implement their own client which, when given user credentials, may act on behalf of the user. This does not seem a likely attack, as phishing is similar and yields bigger benefits.

The following questions are still unanswered for me:

1. What is the difference between the Client Credentials flow and the Resource Owner Password flow? Which one should I prefer? The answers to this question do not give me a clear understanding of the difference.
2. Are there any major security concerns with using the implicit flow, or is it viable?
3. Is embedding the client_secret safe?

• If not, what is the alternative? Should I still require a client_id, or allow using "public" (unregistered) clients?

Answer 1

First, lets make one thing clear -- OAuth2 is authorization so keep this in mind.

Next lets try define things further:

Resource Owner

These are credentials you use when you want to grant access to something like Snapchat wanting to login via FB.

Client Credientals

This is credentials which identify a client, for instance a moblie app or an in-browsers application. E.g you can't use approved Snapchat access with approved Instantgram access.

Exmaple

• You login to Snapchat via FB.
• You get redirected to FB to authenticate and/or authorize Snapchat. The app is requesting an access grant to access your resource (I.E FB Profile).
• You approve and Snapchat send the grant to FB, which gives Snapchat an access token, which it can than use to access your friends list.

Security Concerns around Implicit flow

There are relevant security concerns about. You can see it discussed here on SO and here on Thread Safe. In general, it's a viable practice and you just need to account for some (what should already be on your mind) security best practices.

Lastly, to embedded keys

I suggest you don't. I direct you to this stormpath blog entry about this exact concern. This is mostly around JWT but applies to Oauth2.

Answer 2

It's not safe to save the client secret on the mobile, so I will work on question 3.

I don't a have a solution, but I will explain a alternative that could mitigate the risk of saving a client_secret into a mobile device.

An alternative that you can do would be the usage of installation credentials instead of client credentials. The client credentials will have a parent relationship with installation credentials.

Client Credentials 1
Installation credentials 1
Installation Credentials 2 ....

The idea is to use a security channel backend to backend to generate installation credentials. You gonna need to create a service, where you receive a APP credentials and return a Installation ID. In addition, the mobile application owner will need to create a service where the user request a installation credential.

Basically,

Mobile APP -> BackEnd(Mobile APP Owned) --> BackEnd (OAuth Owner)

This solution doesn't solve your problem, but it mitigate a risk of expose secret. You will get a installation credentials and can use it on your OAuth flow. If some get the secret, it can impersonate only a single user. The attack will not scale.