41–50 of 114 posts
My project supports multiple storage back-ends (mostly around document storage) and I would like to get Kratos to query the same ones, even if it requires dev work on my side to add support.
Earlier quoted context omitted.
Hmm. (I work for FusionAuth, thanks for giving us a try!) So you want a screen in front of the login process where someone enters their email address, and then a second screen where a variety of login options are presented? Along with the ability to enforce MFA on a per domain basis? Anything else you are looking to customize at the domain level, such as password rules or registration ability?
For the moment our needs are actually fairly light. I'm trying to remember exactly what I ran into with FusionAuth but struggling a little unfortunately.
Other than that I'd suggest putting a page in front of our login pages with the domain logic, and modeling each set of emails as either an application, organization or tenant, depending on the specific features you need.
Either way, hope you find the right solution for your needs!
Seems like a good place to ask: Does anyone have advice on good solutions for B2B SAAS apps? Just our app that needs logging in to and would like to allow the usual things (password, social etc) but also allow customising the rules per email domain. For example, if someone enters someone@example.com in to the login form they'll be shuffled off to this Azure connection for authentication. Or maybe they use our login p…
Have a look at ZITADEL ( https://github.com/zitadel/zitadel or https://zitadel.com/ ), I think that does what you want. You can create multiple tenants (called Organizations) and you can setup security / login rules per organization such as enforcing MFA. Furthermore you can configure on each tenant a separate SSO and users are directly forwarded to their identity provider. When you first enter your username (could b…
ZITADEL was already on my list to try in the next round.
Can you clarify the pricing / plan required for that feature set?
Earlier quoted context omitted.
For the moment our needs are actually fairly light. I'm trying to remember exactly what I ran into with FusionAuth but struggling a little unfortunately.
Gotcha. We definitely don't have fine granularity around when MFA is required (open issue here: https://github.com/FusionAuth/fusionauth-issues/issues/2285 ). Other than that I'd suggest putting a page in front of our login pages with the domain logic, and modeling each set of emails as either an application, organization or tenant, depending on the specific features you need. Either way, hope you find the right solu…
> SMS support I thought it was well-established that SMS text messages should not be used for authentication purposes? Here's the original feature-request: https://github.com/ory/kratos/issues/1570 - user @zepatrik raised concerns about this and everyone else just ignored him. Yikes.
What you absolutely shouldn't do is allowing password reset only via SMS token, because it's often not that hard to get access to SMS codes via social engineering (convincing a store clerk to issue a new SIM card, or stealing a phone and getting the code displayed on the lock screen)
Having SMS as second factor requires the attacker to know the password AND do some social engineering. It's a significant security improvement over password only.
SMS might even be safer than password less passkey login, if the user's passkey implementation is unsafe. It's possible to store passkeys in password managers, and people regularly manage to get their vaults compromised. This might only require a keylogger on a PC where the user logs in to the password manager.
> SMS support I thought it was well-established that SMS text messages should not be used for authentication purposes? Here's the original feature-request: https://github.com/ory/kratos/issues/1570 - user @zepatrik raised concerns about this and everyone else just ignored him. Yikes.
Yes, this is definitely true. However, there are use cases and companies who rely on SMS based two-factor: - Using SMS for phone verification - Using SMS for mobile login (think dating apps for example) - Using SMS for two-factor where other factors are not available / convenient (often in emerging markets) SIM Swap Attack, SIM Port Hacking are all real, but as always in security it comes down to your threat model to…
SMS token is something that is much easier to use. 2FA with SMS is still a lot of added security in comparison to no second factor at all. Especially for people who use insecure passwords.
> SMS support I thought it was well-established that SMS text messages should not be used for authentication purposes? Here's the original feature-request: https://github.com/ory/kratos/issues/1570 - user @zepatrik raised concerns about this and everyone else just ignored him. Yikes.
Yes, but if you want large enterprise customers such as regulated financial institutions where lots of money's at stake, you will need to support SMS as a second factor, mothers' maiden names, and bypassing all that when the user has forgotten.
Earlier quoted context omitted.
Have a look at ZITADEL ( https://github.com/zitadel/zitadel or https://zitadel.com/ ), I think that does what you want. You can create multiple tenants (called Organizations) and you can setup security / login rules per organization such as enforcing MFA. Furthermore you can configure on each tenant a separate SSO and users are directly forwarded to their identity provider. When you first enter your username (could b…
That sounds like just what I want. ZITADEL was already on my list to try in the next round. Can you clarify the pricing / plan required for that feature set?
Congratulations, this is a big release. Some great features in there. Love the phone number as a first class citizen, something we've been considering for a while. (I work for a competitor, FusionAuth.) I noticed account linking, between social accounts and existing accounts, based on email matching, was a new feature. It's documented here: https://www.ory.sh/docs/kratos/social-signin/link-multiple-p... I believe. Th…