oauth2: resource owner password credentials proposal #214

[aeneasr]

Proposal

The idea is to make the OAuth 2.0 resource owner password credentials proposal a part of Hydra. This is currently not possible because Hydra does not have access to the user database. There are two obvious solutions available:

🅰️ HTTP API

We could specify an HTTP API that Hydra calls in order to authenticate users. The identity provider would have to implement that API. A request could look like:

POST /oauth2_login
username=foo&password=bar

{
  "valid": true
}

🅱️ Consent flow

Instead of making an HTTP request, we could redirect the user agent to the consent endpoint and pass a consent challenge that contains the username/password. The consent endpoint would validate the user data and generate the consent response automatically and redirect the user agent back to hydra, which in turn issues the access token.

Todo

• remove unsupported note from documentations
• add documentation how this flow works

Vote 👍 if you like 🅰️ and ❤️ if you like 🅱️.

[ventayol]

Hi @arekkas,
what's the status about this?

Currently to do user login we are creating a client for each user on the system, so we can get a token and a refresh token, it's not the best solution but let us move forward. We really miss a way to do the password grant.

[aeneasr]

What are you using the ROCP grant for? Mobile apps?

[ventayol]

For a website, we are using micro-services architecture, so we have a user service that store users and then we have a frontend that connects to this user service via oauth2.

For creating a new user, we use the client credentials, but once the user is created we need to do a "login" with that user. We don't want to code any login form for that on the API as it needs to be customized for each frontend that creates users. So we would like to use ROCP for this.

[aeneasr]

I don't fully understand your flow. Could you elaborate? In general, you can always avoid the ROCP grant. The IETF included it only for migration.

[ventayol]

Let me explain the case better.

Our system has:

• Hydra as oAuth Server
• A user service that provides an API
• A website where people can singup and modify his data

Our workflow will be the following, first let's see how to create a user:

• The website calls hydra to get a client token using client credentials
• The website shows a form to the user to fill the signup information
• Then it calls the user API with the client token to create the user
• The user API check the token against Hydra using introspection endpoint
• If everything is ok, it creates the user and returns OK to the website

Now that we have a user on our system, he wants to login to get his data. The expected workflow will be:

• The website shows a login form to the user (pay attention that it's the website that shows the login form, not the user api)
• Once the user has put the email / password it should call Hydra with ROPC to get a token for that user
• With the user token now he can call the user api
• The user api will use again the intorspection endpoint to check the token against hydra

Are we missing something or doing something wrong?

[aeneasr]

Are we missing something or doing something wrong?

A little bit, because you're mixing an authentication process with OAuth2, which is a protocol for delegating authorization. It leaves you vulnerable to attacks in certain scenarios / set ups.

To work with Hydra, you will need to set up a proper consent app. It does not sound like you have done so. But the consent app is the backbone of how Hydra works and delegates the authentication part.

You will be able to get the same user experience you have right now if you add a consent app. And then you can avoid the risky, outdated, and booed ROCP grant.

We help various businesses (especially in finance) with setting up a proper security architecture and finding the right fit for Hydra in it. We are also auditing existing security architectures and will hint to potential issues. If this is interesting to you, drop us a line at hi@ory.am

[aeneasr]

I took a long time for this issue, primarily because I felt very uncomfortable implementing it. The ROCP grant is something from the "dark ages" of OAuth2 and there are suitable replacements for mobile clients, such as public oauth2 clients, which are supported by Hydra: https://tools.ietf.org/html/draft-ietf-oauth-native-apps-09

The OAuth2 Threat Model explicitly states that the ROPC grant is commonly used in legacy/migration scenarios, and

This grant type has higher
risk because it maintains the UID/password anti-pattern.
Additionally, because the user does not have control over the
authorization process, clients using this grant type are not limited by scope but instead have potentially the same capabilities as the
user themselves. As there is no authorization step, the ability to
offer token revocation is bypassed.

Because passwords are often used for more than 1 service, this
anti-pattern may also put at risk whatever else is accessible with
the supplied credential. Additionally, any easily derived equivalent
(e.g., joe@example.com and joe@example.net) might easily allow
someone to guess that the same password can be used elsewhere.

Impact: The resource server can only differentiate scope based on the
access token being associated with a particular client. The client
could also acquire long-lived tokens and pass them up to an
attacker's web service for further abuse. The client, eavesdroppers,
or endpoints could eavesdrop the user id and password.

o Except for migration reasons, minimize use of this grant type.

• source

Thus, I decided to not implement the ROPC grant in Hydra. Over time, I will add documentation how to deal with mobile scenarios and similar.

[aalimovs]

@ventayol did you end up carrying on using Hydra for your setup?

@arekkas I'm looking for a similar setup that @ventayol explained and was looking to use ROPC as well.

My understanding about adding the consent app is it will be using the Authorisation Code grant? If so, how would you do a silent authentication in this case for a trusted, first party client?

The setup we're both after is using OAuth 2.0 only for internal, trusted clients, that's why I believe there's a use case for ROPC. In this case, there's a trusted front-end (client) with a simple login page for your app that challenges you with a username/password, and on success has a valid access_token for you that you can use down the line for your microservices.

Being new to OAuth 2.0, I'm not sure how can you achieve a simple, silent login for your own app without breaking the UX, asking the user about giving consent to the app he's logging in to?

Thanks!

[aeneasr]

ROPC is discouraged officially by IETF and must not be used for new applications. Since you implement and control the consent app, you can easily skip authentication for logged in users, or skip the consent step for internal clients:

• https://ory.gitbooks.io/hydra/content/faq/ropc.html
• https://ory.gitbooks.io/hydra/content/faq/mobile.html

[gentunian]

Interesting discussion here as I was reading about this project to implement oauth2.

Confussion gets in the middle after reading [this article](https://auth0.com/docs/api-auth/which-oauth-flow-to-use advicing) followed by this one to use the ROPC flow from a site like oauth.com without mention anything about this.

Anyway, @arekkas links are broken, I will leave here what I suppose they are the new links:

• https://ory.gitbooks.io/hydra/8-faq/0-README.html#why-is-the-resource-owner-password-credentials-grant-not-supported
• https://ory.gitbooks.io/hydra/8-faq/0-README.html#how-to-deal-with-mobile-apps

[aeneasr]

Auth0 deprecated the terrible mess they made before they became an OpenID Connect certified provider. It's actually in the two links you posted.

They deprecated them because they are bad design and encourage insecure behaviour. I hope this answers your question.