SMS is an anti feature at this point. This just moves the problem. Arguably email is actually better than SMS and that's not saying much. It's the difference between getting stabbed and shot.
What's the most common thing that people have stolen: wallets and phones. Lots of people have cheap phones, pre-paid sims, or worse. Tying your identity to some phone number that should be treated as temporary only to get locked out of your account some years later is just not great.
Here's a list of reasons people change phone numbers:
- they have a prepaid number and they switch to a different provider
- they travel and use a different sim while traveling
- they change job and lose access to their employer provided phone
- they change operator and the operator declines to take over the old number (happened to me in Germany)
- their phone number ends up on some list of scammers and to get out of the non stop spam by simply getting another number
I discovered another reason to avoid SMS OTP: I am currently visiting India and I have put my phone in Airplane mode because my Canadian phone company , Rogers,charges $15 per day for roaming and it is simply cheaper to buy an Indian SIM card and use it on an old phone to act as a wifi hotspot for my actual phone. So while my phone is in Airplane mode, I am unable to use my RBC Visa or MasterCard for any online purchases in India as there is no way for me to get the SMS OTP without paying Rogers the CA$15 .
That is very high. Australian providers offer free incoming SMS even when roaming internationally. The charge is only for data which you can disable. Vodafone Australia has $5/day roaming.
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.
The document walks through the "linking an existing account with a password to social account" scenario. I was wondering if there was also the ability to go the other way, from an existing social account to adding a password?
How do you handle the case where Alice signs up with a username of alice@example.com but later wants to link alice@gmail.com?
I also wonder if you can block account linking on a per user basis or if it is enabled for everyone in a system.
We do have all edge cases brought to us solved in terms of account linking and the recent changes further improve the user experience in these scenarios. There are many credential types around these days from passkeys to OTP codes to passwords and OIDC. The biggest challenge is always ensuring the flows are secure which is the hardest part in our view.
ps: I find it a tad frustrating that on every Ory post FusionAuth is shilling in the comments, even if the comment is tangential but clearly intended (through links and name dropping) to draw attention away. It would be much better if FusionAuth focused on releasing open source themselves and truly contributed back to the security community instead.
That's great you covered all the use cases you've seen. I'm sure you'll continue to build out this useful functionality. Agree that making sure the flows are secure is critical.
> ps: I find it a tad frustrating that on every Ory post FusionAuth is shilling in the comments, even if the comment is tangential but clearly intended (through links and name dropping) to draw attention away.
Hmmm. Appreciate the feedback. I try to avoid shilling, be upfront about my employment, and add useful comments to any auth related posts on HN, not just those about Ory.
I have a lot of respect for what Ory has built (for example, I featured your post about multi-region CIAM in my CIAM newsletter: https://ciamweekly.substack.com/p/multi-region-ciam ), but I will bring my own perspective to my comments, and that is definitely colored by my experience at FusionAuth as well as the fact they employ me.
Glad I am not the only one who noticed, and not just Ory posts. Once in a while, the leading question and last paragraph of how “my product X solves this” is okay. Sometimes even informative. But too often and bleh it is like spam.
My experience is that in general edge cases are not kratos strong suit. Works very well for the base case but anything fancy you are generally on your own. But I don't mind since it is OSS and someone can contribute/fork if they it.
This is a massive release, well done! I run Kratos and Oathkeeper self hosted on ECS for our onboarding app (Xero only in Australia for now I'm afraid, xonboard.com.au). Works like a dream for the most part.
One thing which was very painful was adapting the custom UI. I started with an existing example project and adapted it but it was a confusing mix of server code and CSS in JS which made it very difficult to "get at" some of the HTML / CSS.
> One thing which was very painful was adapting the custom UI. I started with an existing example project and adapted it but it was a confusing mix of server code and CSS in JS which made it very difficult to "get at" some of the HTML / CSS.
I cannot wrap my mind around why the vendors don't separate the UI and backend application; and then in the UI project, author it in something ubiquitous like React.
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 decide what's acceptable risk and what isn't.
Plus you have to consider the amount of support you inherit when using something less universal (and generally fool-proof) than SMS.
"The one-time code won't work!"
"The authenticator app doesn't work!"
"The email takes forever to arrive!"
"I never got the email!"
Most of that sort of thing goes away with SMS. It's not that SMS never fails, but every mobile device takes it, it's relatively simple, and very reliable. An alternative approach may be more secure, but require more hand holding, and not every organization wants to do that.
In a similar vein, it's not necessarily prudent to do everything that infosec experts espouse. For an analogy, businesses should consult lawyers, but if they follow every bit of advice from a zealous lawyer, they might never take necessary risks that allow the business to achieve excellence; as well, they may need to dedicate substantially more time and effort on compliance.
> - Using SMS for mobile login (think dating apps for example)
Dating apps in particular seem to be a problematic example to me. In some regions, phone numbers change owners quite easily (e.g., no possibility to port a phone number to a new contract, and quick re-cycling of the phone number when a contract is terminated).
To be fair, it really depends on the region you're operating. Some regions (like most places in Asia) use this as the primary identifier (instead of email), so despite the very obvious security flaws you might be simply be forced to offer it.
Right, by this point the global norm is to rarely, if ever, use email (or a computer larger than a smartphone) unless you work in an office (and in some places not even then). The phone number is the primary identifier for mass-market apps in most countries.
It's not just emerging markets. Many people are not capable of setting up authenticator apps, not everyone is a "techy" and not everyone is smart. Those people use the internet too.
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.
> Many people are not capable of setting up authenticator apps, not everyone is a "techy" and not everyone is smart.
That might be true but on the other hand most companies using Teams etc. will be introducing 2FA with the MS Authenticator App. Techie or not, you need to install an app and scan a QR code.
Once again, not every person using the internet is working for a company.
If you don't know anyone that will just laugh at you when you tell them "it's super easy, you just need to install an app and scan a QR code", then you're living inside a bubble. Every year at my mums birthday party her friends already queue up in front of me, so I can install some apps for them.
Are they too stupid (I don't mean that in a condescending way) or just too lazy? I know several elder people (75 to 85 years old) that have no problem installing apps on iPhones. On the other hand I know others that "play dumb" but I think it's mostly an issue of fear.
I agree with you, SMS as implemented almost everywhere* is bad, adding an account takeover path (the reset by SMS) with insufficient value-add to offset that 100% guaranteed (see research I linked elsewhere in thread) path to account takeover.
And as to "You're not seriously saying that adding a second factor is reducing security?" -- yes I am, when it's not a second factor, it's implemented as an "only factor".
* Note: And by "as implemented almost everywhere", I mean so indistinguishable from everywhere that that effectively boils down to "SMS is bad", much easier for users and builders to understand, when better options are available.
It mostly doesn't make sense, unless used exclusively as second factor, never only factor.
- phone verification: OK, but this wasn't about that, and having to have phone numbers in a database means you're maintaining PII, which is a liability, see regulator-related story below.
- mobile login (think dating apps): should be passkey, sign in with Google/Apple, or oauth of users' choice, see Twitter story below
- two factor where other factors are not available: in the case of SMS this actually means for two ways to get into the account, not two factor, see IsSMS2faSecure slides below.
SMS is an anti-pattern, generally less secure than a good password (something you don't even need to know w/ passkey) and biometrics (something you have/are) as it opens your threat model up to anyone with social engineering skills to take over your account (something anyone can do).
This was demonstrated dramatically a few years back by a research team calling the phone companies and being 100% successful on major carriers.
The slides here are eye opening if you're thinking SMS is a good idea:
We have the $400M FTX sim swap and this year the SEC's sim swap to remind us nobody is immune when SMS is at play, and people can't claim to not know about it since it's now widely covered:
The FTX case highlights a growing awareness among prosecutors and regulators of the ease and prevalence of SIM swap schemes. Reading the Powell indictment is not unlike reading one of the hundreds of credit card theft indictments that federal and state prosecutors pursue each year. As far as frauds go, SIM swapping is low-cost, unsophisticated, and rote. But, if you’re a criminal, it works.
SIM swapping works largely as the result of vulnerabilities in the telecom’s anti-fraud and identification protocols, and as the result of relatively weak anti-fraud and identification verification procedures used as the default for all too many online service providers, including financial services firms.
Bottom line, and putting this "global user" story to bed, if Twitter can dump SMS across emerging markets (not a lot of blue checkmark subscribers), so can everyone:
All that said, @andix is correct in that if you're going to use it, you must not allow password resets or account takeovers with SMS. SMS must be strictly second factor, never "only factor": https://news.ycombinator.com/item?id=39467039
SMS 2FA is only ostensibly about security. Mobile providers always sucked at it and never advertising that they were selling high quality identification services in the first place. They've actually gotten better at it but it wasn't ever there thing and still isn't.
Phone numbers are excellent PII for user tracking though AND allow companies to dump a lot of the hard support work on some one else. Gobbling up PII to sell and externalizing the hard support stuff to some one else is how tech companies and increasingly any company works these days. So it isn't a surprise it isn't going anywhere. You'll likely need to cough up a number at least for "verification" anyway (since they want it) so they'll probably just use that for account recovery to while they're at it to make their lives easier.
It depends. Using SMS as a second (!) factor is fine. There are better options, but SMS is much better than no second factor at all.
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.
> I thought it was well-established that SMS text messages should not be used for authentication purposes?
Using SMS text messages for 2FA is barely better than 1FA, but it is better.
There's a lot of value in discouraging what many see as the easy option, especially when the alternatives are getting users to install extra apps (or even buy hardware keys of some sort), so the scaremongering around SMS is warranted, but it's still absolutely better than nothing.
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.
It would be lovely to have that in the U.S., but I doubt it will go anywhere anytime soon.
I'm sympathetic to the reasons. The U.S. has a massive population of people who for various reasons will not or cannot adopt methods other than SMS, if that.
Meanwhile you can call up some of our largest financial institutions and impersonate someone with public-record knowledge. Many organizations will allow you to skip any kind of over-the-phone SMS challenge by asking for -more- publicly available knowledge to "better"/further authenticate the caller. And of course all our Social Security Numbers are effectively all out there, and those are still the de-factor identifier where a phone number is not.
I used to do business with Vanguard. Several years ago they rolled out U2F-then-WebAuthn support so you could use a Yubikey or other FIDO2 compliant token as your MFA method. They allowed you to disable SMS MFA if you did that. I happily enabled that. Within two years, they re-introduced a requirement to enroll a number for SMS MFA on the grounds that their mobile app only supported codes delivered by SMS, and there was no opt-out. If you didn't enroll a number you'd be locked out and have to call customer service to add a number and reset your password.
Still funny to hear that everyone in the US has a social security number, although there is no public healthcare for everybody. And I always thought it's the land of unlimited freedom, doesn't seem to apply to privacy.
I have a social security number too, but I need it to get free (actually less expensive) healthcare. Not for opening a bank account. I think in my country nobody except health care is allowed to process social security numbers, because it's considered private information. They are not allowed to store them. If they get them by accident they need to delete them ;)
That's either recent or wrong, I'm in the UK and certainly they're not new since 2019 or whenever we left (I was going to say 16 but I realised that was the vote not actual exit, but longer than that anyway).
We have PSD2 though; I think we're voluntarily (or perhaps conditional in the exit negotiation) signed up to it anyway, perhaps so that 'open banking' works internationally still?
Just from a cursory 'psd2 sms multifactor' search, I can't see anything definitively saying it's not allowed though? I can see 'must use secure MFA' (implying it might be pretty open to interpretation) and blogspam type sites saying 'the short answer is yes [SMS can be used]' or 'can be as simple as implementing SMS and voice'.
This one seems reasonable - https://www.onespan.com/blog/psd2-end-sms-based-authenticati... - and though his opinion is that it's not up to scratch, it does make it seem like it comes down to interpretation and your willingness to defend your position. Unless you know that it literally says 'must not use SMS' now?
Two examples I can think of are Santander, and NS&I (run by UK gov). The latter might not be a 'payment service' though I suppose (savings accounts only). I think NewDay (rebadged credit card aaS provider) too.
You can use social engineering (or corrupted workers) to issue SIM card for other people and receive SMS. This method is widely used to steal money from bank accounts in my country. Telegram accounts also known to be stolen this way.
Of course you should be located in the same country. But it's a risk nonetheless.
SMS is better than nothing, but I personally know several people who had their accounts compromised because their SMS 2FA codes were intercepted. It's not possible to do this with TOTP.
How were they intercepted? Was it a sim takeover, where the attacker took over the phone number? Or intercepting the code over the air, since SMS has no encryption?
How can I someone see other's messages? Surely someone has step by step guide if it is that easy. Are you sure it was interception without SIM takeover?
It's not that you can do this just from any old device by flipping a built-in switch, but it's not that different from observing plaintext traffic over an Ethernet network with the right software.
There are various ways to nab an SMS. Some are similar to SIM swap attacks in that they rely on social engineering or human or process fallibility to execute [1] [2], and others can grab messages right right out of the air, so to speak [3] [4]. This is in part because one of the foundational protocols that underlie modern cellular networks was never designed with modern security in mind. It's called SS7, and it's been extensively documented as a concern to the security of cellular based communications [5] [6] [7] [8].
Lot's of references because this is an area that has long fascinated me, and I have many bookmarks. There are also some recent papers on this behind paywalls (e.g., [9]).
In between the lines and lightly touched on in some reporting is a nuanced point that I think plays a larger part - one issue is that overhauling these older foundational technologies isn't just a matter of commercial and standards changes but also moving the goal posts on where lawful interception happens in the stack, how it happens, and the technologies that support that. For example in the U.S., law enforcement agencies can acquire devices that impersonate cellular infrastructure in order to force communications to go through law enforcement controlled equipment (called IMSI catchers). If we were to revamp cellular networks with a view toward security in the way we probably should, it's reasonable that devices like that wouldn't be feasible without being operated by the telephone companies that own the networks, and that would probably become some amount of red tape that law enforcement doesn't like.
Again, I want the tool through which I can see other people's messages, or at least a video of some hacker doing that. e.g. I can observe plaintext message over ethernet by using some splitter and wireshark.
there are tons of articles here in HN that have shown that SIM swamp (at least in US) is much easier then trying to brute force (or using quantum computer) to break TOTP encryption. One of main reason for SMS is also meta data collection of your number.
It’s not the same. The explanation you quote is wrong.
This is the correct one:
> SIM cloning is the procedure through which a genuine SIM card is reproduced. When the cloning is accomplished, the cloned SIM card’s classifying information is transported onto a separate, secondary SIM card. The secondary card can then be used in a different phone while consuming all the calls and related charges credited to the original SIM card.
> no one has shown any concrete proof that SMS could be hacked more easily
On the contrary, here is an empirical study demonstrating 100% of the 5 major carriers in US used insecure authentication challenges that can easily be subverted by attackers:
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 pages, but MFA is enforced.
Things that I've tried (eg Authentik and FusionAuth) weren't well suited for per organisation controls.
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 be an email) on the login screen, the policies of the user's organization will be applied. That allows you to route users based on their email domain etc.
One additional thing to mention is that ZITADEL does not only handle authentication, but also authorization with self-service. Managers of an organization can, for example, assign users of their organization roles.
All of these features are included. Main drivers for pricing in this case, I assume will be daily active users (sum over the month) and how many third-party identity providers you have configured. Unlimited tenants, users, permissions etc. are included.
We use DAU instead of MAU, since there are many different use cases and that seems work quite well. Just take the MAU and multiply by how many times per month your users will sign-in.
In the enterprise tier we offer more custom quotes for higher volumes, guarantee requirements, and support SLAs.
And to clarify on the third party providers. Assuming every org is using Azure - that’s 1 provider per org. So 53 orgs would be an extra $1,000 / month?
Yes that's correct. Get a quote for your use case, if you are already running on higher numbers. Pricing might not fit all cases, that's why there's also an Enterprise tier.
We built Stytch's B2B SaaS solution with this specific shortcoming in mind -- most other solutions aren't actually built with an organization-first data model (they're user-first like Auth0 but support the general concept of orgs), which makes it difficult to offer those per organization controls in an ergonomic manner.
I’m also interested in this. We’ve been using Auth0 for a year and our contract is up for renewal where we will be getting kicked off of the startup plan. I’m wanting to rip the bandaid off early as we’re about to launch a new platform.
I’m highly considering bringing auth in house with Keycloak. I’ve run it in the past at previous companies so am familiar with it, but it’s going to be an extra thing to maintain due to self hosting, their themeing also is not great. However this is pretty much an end all solution that doesn’t really get expensive over time as our user base grows.
No, I haven’t tried it. It looks great but unfortunately the per connection pricing makes it not ideal for us. (We’ve had a couple of messages back and forth on here in the past about it). Most of our customers have low numbers of users, so the per subscription cost becomes a bit high.
I’ll kick the tyres in my next round of investigation though to see how it looks.
Auth0 can do this. Identifier first login, SSO domain aliases, and MFA are all supported. They have an Organizations feature as well, but I'm not certain if you'd need that from what you've described. Customization of various aspects of the authn flow can be done via Actions (and Rules, but they're deprecated).
The flow is essentially what you see in the small video on the docs page and can be set up in the Ory Network Console with a few clicks. I agree though that the docs here are a bit thin.
Pricing wise this is available on the Scale tier currently dubbed as "Enterprise SSO" although "B2B Organizations" probably would be more correct: https://www.ory.sh/pricing/
There are no limits to how many organizations you can have.
Regarding MFA - the MFA enforcement typically is the responsibility of the IDP the company owns. So for example dean@companyA.com use Okta and they enforce 2FA for their users. anna@companyB.com use OneLogin and they do not enforce MFA.
In terms of other enforcement, I meant more wrt to an organisation that _didn't_ use another IDP but still wanted to apply PW policies (for example) on their domain.
Could you create an Ory project (sorry, don't know all your terminology) to forward on to?
Something like:
Our app -> Ory -> split by domain -> Ory for specific domain -> Policies.
Most of the commercial solutions break financially when you have a freemium tier; orgs that don't pay below a certain size or usage. Yet the auth provider charges you the same fee for each such org.
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!
Ory Kratos is an identity management solution with MFA, passwordless, WebAuthn and so on, so I would argue for most use cases it alone is comparable.
But there are two more Ory services; one for permissions / authZ and an OAuth2 server. You can make use of those to cover the full range of authN/authZ use cases.
Note that this software unethically phones home with your usage data without your consent. Such opt-out, on-by-default spyware exfiltrates your data silently. They claim it’s anonymous, but that’s false as it includes your client IP address, which frequently maps directly to physical location.
You have to patch it out, because even if you try to turn it off, it still phones home in violation of your expressed wishes:
> Disabling telemetry doesn't have any downsides, except for us not being able to improve the project. Note that Ory always sends minimal ping with version information once on start up.
Why do people feel entitled to spy on users of the software they gave away? I would never, ever even consider using their SaaS, or that of any other company these founders ever run.
Kevin Goslar, formerly of Google (per his GitHub profile), is the one that committed this code (per the history publicly available on GitHub). It is somewhat unsurprising that free software at his new startup follows the same ethical framework regarding nonconsensual surveillance as the world’s largest advertising surveillance company where he used to work.
The trend of open source spyware is increasing. We need to be more vigilant both about the presence of spyware in open source software, as well as being mindful of the people who engage in such unethical practices. (For instance, Mattermost is another offender in this category.)
If you look in the source code for this software which is provided for everyone to see you will realize that Kevin Goslar is entirely innocent of this heinous crime.
He merely added the copyright headers to each file.
You misunderstand the purpose of the SQA telemetry.
There are some reasons for SQA telemetry listed in the doc you posted:
- Be able to say how many production deployments exist.
- Understand which features are used and how.
- Understand how much throughput deployments handle.
- Evaluate how frequently specific features are used.
- Detect issues introduced by new features (such as a buggy releases).
- Identify problems at scale (such as slow endpoints).
- Understand which versions are deployed.
If you have concerns about privacy as you rightly noted you can turn it off with a simple flag (--sqa-opt-out) and if you don't like the version ping you can block in your network. Hundreds of users are running Ory Kratos without any telemetry sent without any extra work.
So if this is a plot to produce open source spyware it's not the best.
This practice being considered acceptable has been a nightmare - we had OSS libraries add spying later, change their APIs for disabling it, etc. When it's a nested dependency, even worse.
Now and then we run our stack with mitm monitor just to sniff out this dangerous crap. More recently, we are seeing it in ML libraries. For a security vendor to do it is extra bad because they can't claim not understanding why it's bad and often illegal.
Developers are not entitled to knowledge of what software runs or does not run on machines that do not belong to them.
To co-opt those machines without the consent of the user or device owner means your software is malware. To do so even after the user has explicitly opted out is even worse, and in my opinion, is criminal behavior.
With consent, it’s fine. Without consent, it is the same as any other spying.
If this is indeed "spyware" (which it isn't) they sure do a poor job of hiding it from you.
Going so far as to tell you exactly what sort of harmless data they're collecting and even putting the code for doing so in a public repo, and then even letting you opt out of it.
Doesn't sound like any kind of spyware I've ever seen.
Ory Kratos is using 7 docker containers to run, seems super heavy compare to Keycloak that will run with just 2 containers. What is justifying the bloat?
I looked at using the Ory stack when they were much younger, and had some chats with their team. Ory builds everything with the expectation that you're a large enterprise, where service classes and systems are expected to be scaled. They're also pretty big k8s adopters, so they all but expect that you want to run your workloads in a large environment. Great for folks that are bringing Auth* home from Auth0/Okta, etc, as scaling for each app class is right there, but also a much more complex stack to begin with.
That said, where are you seeing 7 containers? I haven't grabbed the repo to run it, but their quickstart instructions use config overlays to manage specific configs, and none of the examples looked like more than 5 containers, 4+ your database, with 1 of them being a dev mail endpoint. Separating tasks out to 3 different services, frontend, backend, and DB migration, doesn't seem super big to me.
Been using it in production for a bit less than 2y now. It has improved a lot, the configuration is still kinda hard (jsonnet is really ugly IMO) and there are a lot of weird decisions (like you can change the password without knowing the current password if you have login within the last X minutes even coming from a social provider) but overall it is a solid contender in the space now.
I always wanted to use Kratos for my own open-source projects, but I never got far enough into the researching how support for adding different storage options is.
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.
We have worked quite a lot on making Ory Kratos easier to consume. In the release notes you find ~4 CLI commands you can use to get a fully working Ory Kratos up and running, with all UIs and configuration management :) You should give it another try!
Unfortunately this is not comparable to authentik for me, it looks like it’s only for applications you’re developing and not already implemented solutions
passwordless via email is the single thing that I've been waiting for, once I integrate this I can disable Auth0 and still support the OSS SaaS forum platform — this previously required an Auth0 account, and has sent Auth0 at least 10 medium sized customers.
SMS is an anti feature at this point. This just moves the problem. Arguably email is actually better than SMS and that's not saying much. It's the difference between getting stabbed and shot.
What's the most common thing that people have stolen: wallets and phones. Lots of people have cheap phones, pre-paid sims, or worse. Tying your identity to some phone number that should be treated as temporary only to get locked out of your account some years later is just not great.
Here's a list of reasons people change phone numbers:
- they have a prepaid number and they switch to a different provider
- they travel and use a different sim while traveling
- they change job and lose access to their employer provided phone
- they change operator and the operator declines to take over the old number (happened to me in Germany)
- their phone number ends up on some list of scammers and to get out of the non stop spam by simply getting another number