Two-factor authentication

ericchiang commented 8 years ago

We don't have an immediate need for this but it would be a very cool thing to add. Would ideally use API tokens to integrate with an existing one time password provider.

This feels like an addition to the local connector.

ibotty commented 8 years ago

I am interested in using u2f with dex. There are some notes on using u2f with OIDC from yubico: https://www.yubico.com/wp-content/uploads/2015/08/Yubico-U2F-and-OIDC-Final.pdf

If given guidance, I might be able to devote some time to it.

bobbyrullo commented 8 years ago

@ibotty : that would be wonderful.

I agree with @ericchiang that it sounds like a local connector addition. Consider the different deployment options: requiring 2-factor for all users, user's choice, or not enabled. Also consider how general does this need to be: if it works with yubikey will it work with other vendors?

The way to proceed is to post a proposal here and once we reach agreement you can move forward with an implementation. If you need more guidance don't hesitate to ask!

Also note: I am working on a proposal template, so once that is in please use that if you can.

ibotty commented 8 years ago

U2f is a vendor-neutral standard. It would also work with cheap 5$ dongles.

I will try to do a proposal draft next week.

ibotty commented 8 years ago

I did not get to it a few weeks ago. Sorry. I don't know, when I will have time. So nobody should be discouraged to work on it!

wyattanderson commented 7 years ago

Would be awesome to see U2F support, but we'd also love to have TOTP. We use the LDAP connector, though, so if it could be configurable to work with connectors that don't already provide 2FA, that would be neat.

remohammadi commented 7 years ago

I'm also interested to work on this.

To implement it as a local connector addition, I think we need to rethink about the connector config format. Because in the current format, connectors are ORed with each other (authorizing through one of them is sufficient). I can think of these options:

To make it possible to define a pipeline of connectors in the config. (overkill?)
Another flag for dex-worker, -2fa-connectors for example, to set a list of connectors as the second authenticator.
Have a combined connector (local+TOTP for example)

Which option does make sense to be the base for the proposal?

ericchiang commented 7 years ago

Going to copy and past a comment I added over in #763

Might be something that can be implemented out of scope of dex. E.g. user logs into app through dex, then when they try to do something sensitive the app itself triggers a second factor.

When to trigger a second factor is hard to express in a general way.

Basically, I don't know if dex itself should implement this. Second factor auth is usually triggered by special events, such as logging in from a new device, a new geographical location, or after some predetermined amount of time. Are these decisions general or something that an application developer using dex for auth would want to control themselves?

mounk commented 5 years ago

In recent years, we’ve witnessed a massive increase in the number of websites losing personal data of their users. And as cybercrime gets more sophisticated, companies find their old security systems are no match for modern threats and attacks. Sometimes it’s simple human error that has left them exposed. And it’s not just user trust that can be damaged. All types of organizations—global companies, small businesses, start-ups, and even non-profits—can suffer severe financial and reputational loss. I watch this vedeo to an article Bluestacks TextNow Photomath

rosskusler commented 5 years ago

Increasingly we're being asked to add 2FA to dashboards and control panels of sensitive applications. The requirement to use 2FA is typically required for every time the user logs in (or their token expires). It would be really convenient to have dex handle this.

jans23 commented 5 years ago

Basically, I don't know if dex itself should implement this. Second factor auth is usually triggered by special events, such as logging in from a new device, a new geographical location, or after some predetermined amount of time. Are these decisions general or something that an application developer using dex for auth would want to control themselves?

I know of enterprise setups where 2FA is obligatory for login and in which case a central implementation in dex would be ideal. For such reasons other solutions like Gluu and PrivacyIDEA execute 2FA centrally.

Morriz commented 4 years ago

Any update on this? Central 2fa is or should be the standard nowadays. So dex is missing out adoption and thus losing will to live...I am no Go programmer unfortunately, and low on availability atm.

daenney commented 4 years ago

I'm going to focus my response on FIDO2 here since I'd be up for contributing code to make FIDO2 happen.

Looking at supported connectors, most already support MFA in some form. If you use GitHub for example and have MFA on your account, you'll get prompted for it based on if GitHub decides it's necessary (and you can enrol a FIDO2/U2F key with them). The same holds for just about any connector in Dex, including OIDC, assuming whatever provider you delegate to supports it.

The one lacking connector is LDAP. LDAP itself has no provisions for MFA or something like FIDO2/U2F. For people using that connector Dex would have to at the very least provide a way to verify a key against a server (like https://developers.yubico.com/u2fval/) but ideally would be extended to allow for enrolment of the key itself so we can keep everything in one place. The nice folks over at Duo already provide a complete implementation for this in Go https://github.com/duo-labs/webauthn and there's a pretty decent blog post detailing on how to use it: https://www.herbie.dev/blog/webauthn-basic-web-client-server/.

On the application side there is support for requesting additional validation by using the Authentication Context Class Reference feature. It comes down to specifying an acr_values claim (voluntary or mandatory) or include it in the Oauth2 authentication request parameters. Authentication Context Class Reference support is mandatory for OpenID providers to support: https://openid.net/specs/openid-connect-core-1_0.html#ServerMTI (though it's fine to ignore it).

Though the application can request additional validation (for example a financial app might really want to ensure a key is used) it should be possible to have Dex force the use of additional validation (for an app) so that an administrator can enforce basic policies for the organisation.

So at least for FIDO2 I believe what would need to happen is:

[ ] Enable FIDO2 key enrolment (https://github.com/duo-labs/webauthn) with a local DB as a backing store
- [ ] Consider storing enrolled keys in LDAP for those using the LDAP connector?
[ ] Extend the general authn flow to allow for an additional verification step. The idea here would not be to limit this only to LDAP. Some other providers might not support FIDO2 so there could still be value in allowing you to layer an additional validation step on top of any connector
[ ] Enable, per app, mandatory additional validation even if not requested through ACR

mvdkleijn commented 3 years ago

DexIDP is a wonderfully light but flexible solution for centralized login and (as far as I'm concerned) a good place to do centralized MFA.

Allowing for a kind of generalized "middleware" plugin that allows a user to insert functionality (like MFA) before or after authenticating with a connector would be very nice.

Having it centralized (at least optionally), would allow for users to write light-weight apps that simply integrate with Dex for authentication and authorization without having to re-invent the wheel / implement MFA per app.

I'd say that offering 3 types of middleware plugins would allow 80% of people to enjoy these features:

TOTP
U2F
FIDO2/WebAuthn

edit: removed some typos

gshamov commented 1 year ago

ping: is there any chance to have Duo MFA done on the Dex side?

nabokihms commented 1 year ago

@gshamov Hello!

We are not actively working towards this feature. As Eric said back in 2017, to implement MFA, firstly, we need to introduce basic session management for users.

Dex has two types of connectors.

Password connector that uses Dex interface to accept credentials and then request API to authenticate a user in an external provider, e.g., LDAP.
Callback connectors that redirect a user to the provider login page and wait for the callback, e.g., OIDC, Gitlab, GitHub.

For the second type, session management is done on the provider side (including MFA). For the first one, adding session management (including MFA) on the Dex side makes sense.