dexidp
"Remember me" when logging in
dex SSO:
To prevent people from having to type their email/passwords multiple times, we propose the following: after dex authenticates or registers, it drops a http-only cookie with a special JWT: one where the ISS and the AUD are the issuer (i.e., dex) Now, when a client app sends someone to authenticate via dex, if they have this cookie (and the JWT is valid, non-expired, etc.), dex will not require them to type a password or email or login via a remote IDP (eg. Google); instead they will see the dex type interstitial that says something like “Such and such app wants to do stuff on your behalf” and they just have to click a button and they will be redirected to the client callback URL with the auth code.
This is still one click too many however. So, when logging in (or registering), dex will add a special claim (something like “known_clients”) that contains the clientID of the oidc client (eg. Creme). When authenticating for these clients, dex will authenticate immediately and send them over to the client callback URL.
This will be indeed very useful. Do you have an idea on when this will be available?
I can't use Dex without this feature. Users don't want to log in for each service we have.
Any news about this issue ?
@rouxcorp not being prioritized on our end but would be happy if someone wants to send a PR.
We'll probably be avoiding a "special claim" though. Just a cookie that gets set allowing a user to forgo their username/password or oauth2 flow and login immediately for some predetermined amount of time.
How this flow can be implemented in the event of key rotation? Does it mean that JWT will be invalid if the signin key is rotated and the user will be prompted for password or social login again?
I'm really interested in figuring out the way SSO can be implemented with Dex.
Maybe it can be something similar to this: https://github.com/coreos/dex/pull/841 ?
Basically it means that Dex would need to manage sessions somehow, and also deal with logouts and etc. which I believe is not the goal for v2, but having some sort of a concept would be really great.
@burdiyan I think this feature quest is just cooking an end user, so when they come back to dex they don't have to login again and are immediately redirected with a new, valid "code" to the client.
I think #990 could play a role here: With this, dex wouldn't have to keep a session (see #963), but could piggy-back on the connector's IdP to do so.
I'd imagine the following flow:
- the OIDC client (say, JS app) notices that the user's token has expired (or was declined, ...), and redirects them to
/auth?id_token_hint=OLD_ID_TOKEN&... - dex uses that
id_token_hintto figure out which connector to use, forwards the browser to, say/auth/okta(let's assume SAML) - that connector does what it always does, and redirects the user to Okta
- Okta, which has session mgmt, doesn't prompt the user again, but redirects them (SAML-style) back to dex
- [...] we got a new token without manual interaction.
Of course that depends on the used connector. I imagine it should work fine for OIDC and SAML. PasswordConnectors are different, of course.
dex uses that id_token_hint to figure out which connector to use, forwards the browser to, say /auth/okta (let's assume SAML)
I really like this approach.
Based on PasswordConnectors, all clients only need to log in once, is this function implemented?
Pinging maintainer: @rithujohn191 @JoelSpeed @srenatus @bonifaido @sagikazarmark
Would you be open to a PR adding this functionality? I see this implementation as having 2 stages:
- Add the
id_token_hintsupport to Dex. This will enable client applications to direct users to a specific IdP and pigg-back on that OIDC/SAML provider's SSO (eg Okta behind Dex). I believe this PR can be more easily merged. - Dex session management for connectors like LDAP. I would expect this to be more contentious as there are many ways to do it and it adds complexity to Dex. However, it is a very common use-case and I'd love to see some support for it. @felixfontein has opened #1574 for this.
I have implemented a login session for the password connectors in this fork: https://github.com/juliantaylor/dex/tree/session-support
It is relatively simple, it just adds the identify and scopes as securecookie to the password login. If this approach makes sense I could post a PR.
I have implemented a login session for the password connectors in this fork: juliantaylor/dex@
session-supportIt is relatively simple, it just adds the identify and scopes as securecookie to the password login. If this approach makes sense I could post a PR.
rebased on the latest release https://github.com/SuperSandro2000/dex/commit/dd0fb05386ce89c74381ce49e903cc10b987459e
Is there any reason the maintainers haven't responded here? Some philosophical disagreement in the idea of SSO perhaps?
Or is it because the Login function is implemented in such a way that each connector would have to implement session management itself?
Can someone please explain to me the concrete use cases and issues that a remember me option would solve? Since Dex often piggy backs on upstream identity providers anyway, I'm trying to understand what it the purpose here and what would the user facing difference be?
For example, I've seen cases of people using Dex in combination with sessions management (eg OAuth2 Proxy) to allow protecting multiple applications before, I'm wondering if combining Dex with other applications could achieve what users want here
When used in combination with LDAP there is not upstream which could solve this.
@JoelSpeed if you use dex with LDAP, you have to enter the credentials every single time if there's no "remember me".
In my case, I have a bunch of applications under two different domains, protected by two OAuth2 Proxy instances, and then there's Apache 2.4 with mod_auth_openidc for some CGI app.
As long as the upstream provider uses the "callback" scheme it will work without any issues. But for me, I want to authenticate using LDAP. And having the user typing the username/password every time an application logs the user in it not a good approach.
We could really use this. I got complaints from our Argocd users that log in through LDAP
In our use case we have two security levels, on for developers and one for operations, we want some of the same services to be reachable from both so we use a common dex with multiple idps. The idp portals are separated by firewall so you cant login to a idp in another security context even if they use the same dex. All our idps (oidc) support sso so after choosing the correct idp in dex everything is automatic. It would be nice to be able to remember which idp a user selects and try to use it the next time the user logs on, as a client(computer) will almost allways use the same idp every time.
I am currently working on this and will open a PR this weekend most likely.
