Support resource owner password credentials grant (username and password login)

[rithujohn191]

This would allow user apps to handle login internally without having to pass the dex login page.

[DusanKasan]

I need this. Can do PR, any pointers as to how to implement it?

As for the API I would probably return a JSON object with "connector": "login_uri" pairs for each active connector. Makes sense?

[bkleef]

We need this as well.

@rithujohn191 could you please get back to @DusanKasan? Thanks a lot!
We've also time for this.

[rithujohn191]

Let me try and put together a design proposal for this soon.

[bkleef]

@rithujohn191 awesome, thanks!

[ericchiang]

Rewording this issue. By popular demand, we're going to explore supporting the "Resource Owner Password Credentials Grant" for password based login methods (local users, and LDAP). This grant allows OAuth2 clients send username and passwords directly to the token endpoint and receive a token response.

This will not work for OAuth2 based backends such as Google, GitHub, etc.

This feature would allow users to set something like the following in their config:

oauth2:
    passwordConnector: free-ipa # ID of an LDAP connector

Then, after grabbing the user's credentials, a client can send them to dex to get an id_token.

No explicit timeline yet.

[snowzach]

I needed this too.. Created PR #1163

[johnharris85]

Looks like there's a few PRs for this in various states, I'm going to try and take one and make it merge-able soon. I'm also curious about the ability to choose what connector that I want to hit (the implementations I've seen so far allow the selection of just one). The solution for multiple backends would either be just to use multiple dex instances (each specifying a different password connector), or somehow find some way of parsing some 'selection' field out of the request. Nothing in the spec for this flow allows for extra POST parameters as far as I can see? However potentially it could be keyed from an HTTP header? Open to ideas 🤷‍♂️

cc/ @justaugustus

[johnharris85]

Thoughts ^^ @srenatus @rithujohn191 ? As part of investigating the above I also found some issues / PRs around 'selecting' a connector in the request (#1138, #1084). While that seems a nice-to-have with regular flows, it's pretty essential for this flow as there's no other (UI) way to select a connector (making a compelling use-case for selection if we want to add this flow). Multi-Dex is a no-go because of k8s support for only a single OIDC provider.

My use case here is that I want to use the ROPG flow and have multiple LDAP backends. In my client I need to be able to select which backend is used via the request somehow. Possible to overload the actual query parameters for this (although that is not in the spec so not particularly clean) or maybe a custom HTTP header (also not super clean 🤷‍♂️). My client (WIP) uses the golang/oauth2 library to talk to Dex and it's possible to implement either of those options by passing a custom httpClient / roundtripper to add them and override the default library behavior.

Happy to work on implementations for both the ROPG flow and the connector selection but wanted to hash out the design / approval before I start.

cc/ @justaugustus @alexbrand

[squat]

This is now solved thanks to #1621. We can close this issue IMO

[tomqwpl]

Although Dex itself now supports password grants, it only does so to the LDAP connector I believe.
My guess is that there are further potential PRs for supporting password grants on, e.g, the microsoft connector. I believe that microsoft authentication server supports password grants, so I'm assuming that this is theoretically possible.

[meimeitou]

up

[degibenz]

up

[withlin]

up