Require second factor only if device is unknown ("remember this device")

[aeneasr]

Is your feature request related to a problem? Please describe.

It would be great to have a feature which would allow us to configure to "trust" a device. This is common practice at Google for example, where, once you performed MFA on a device, a cookie is set to remember you on that device. This means that you still have to authenticate using your password from time to time, but you do not need to complete the second factor every time!

Describe the solution you'd like

Basically, this should be configurable. So enable/disable.

Additional context

This needs #1624 to land first :)

[zambien]

There are often dynamic risk-based decision platforms that come into play here as well. For example, vendors like ThreatMetrix, Outseer, IPQualityScore, and others are able to take input which includes data like IP address, device print, etc. to decide if a user should be MFA challenged. The ability to plug in and change the decision based on a webhook is probably important here, but it might be a separate feature.

[zambien]

A relatively simple proposal on how to handle dynamic MFA:

MFA configuration can be setup with flags like:

always, never, device, external

Where always means to always MFA challenge the user, never is never (not sure this is needed), device would be device based, and external would allow some external API to define behaviour. The external integration would expect some external service to respond with a specific payload which would need to include an action. This interface would be a standard in Kratos and the backing API has the luxury to do whatever it wants in it's black box.

The action for external decision would be one of: allow, challenge, block, and possibly others. Where allow means authenticate the user without MFA, challenge means challenge with MFA, and block means the user is not allowed to log in at all.

This implementation would solve use cases for Ory Open Source and provide a path for Ory Cloud to offer it's own risk-based decisioning (similar to what Auth0 and other vendors do).

Edit: formatting

@aeneasr and others, what do you think of the proposal?

[aeneasr]

Generally, I think device based trust is nice for two factor verification (not authentication though!).

Currently, we let that decision up to the implementor. You can choose what whoami and settings endpoints need what AAL (1=password,2=MFA). Your application then is able for making the decision whether MFA is required or not. This is useful because MFA can also be something that depends on what the user is actually doing (e.g. changing something sensitive), which is not something a generic policy engine could do.

What we could do though is introduce some type of long living „trusted device“ cookie which stores what users performed MFA on the device. I’m not sure how useful that would be though?

[zambien]

@aeneasr after reading through Ory slack a bit more this approach makes sense. We can have a custom application/proxy layer which decides if an MFA challenge is required and route to a Kratos instance that is configured that way.

[github-actions[bot]]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️