Reputation: 2105
I have been looking around for some time and absolutely no one seem to properly answer the question.
Let's say I have an "untrusted" client application : an AngularJS front-end. This front-end wants to reach my api, so the user must authenticate first in some way.
So if I am using the oauth password flow, the user has to fill his credentials in a HTML form and the Angular app has to send a request appending the client_id and client_secret.
What I don't understand is that everyone and the spec say that the client_secret must remain secret ...
This is absurd, you must send the client_secret to authenticate but at the same time you must keep it unknown from the Javascript ?
So my question is :
How to use the oauth password flow from an untrusted client (web front-end or mobile app) without revealing the client_secret ?
Is it even posible or is it simply not possible to abide by this spec ?
Upvotes: 1
Views: 521
Reputation: 48230
You shouldn't use the password flow, rather use the implicit (aka token) flow which doesn't involve the client_secret.
This flow is designed for client-only apps, including JS frontend apps like the one you describe.
Beside the problem you've noticed, using the password flow from client apps suffers possible authentication issues. Suppose for example the identity provider uses a two-factor auth or maybe delegates the authentication to yet another provider. With the password flow, where this is your app to ask for username/password, there is really no way to handle this. On the other hand, the implicit flow consist in redirecting the flow to the provider and this is up to the provider to authenticate using any available means.
What you get back from the implicit flow is the token you can use directly from the client.
Upvotes: 1