Show HN: Open-Source Auth for NextJS / React
ory.dev
ory.dev
I have some questions:
- Is it possible to have multiple organizations in one single instance? Can I have some superusers that have access to all organizations?
- Can I delegate authentication for a subset of users (in my case this will always be an entire organization) to another authentication provider (say Microsoft ADFS)?
- Do you support SAML 2.0 clients?
- Do you have a REST API which can be used to create / deactivate users?
To answer your questions:
- Is it possible to have multiple organizations in one single instance? Can I have some superusers that have access to all organizations?
Depends how you interpret multiple organizations. If those are distinct users (meaning the same person has a profile in org A and org B and does not reuse them), so a true multi-tenant system, then this is not built in and we do not plan to add it.
Running Ory Kratos is very cheap in terms of resources (few MB of ram and no CPU on idle) so it's very affordable to spin up another instance. This doesn't work well for fully-automated deployments such as SaaS systems, but it does work if you are thinking about corporate systems.
You might also look for Ory Cloud, where you can deploy a new Ory Kratos instance with a simple API call.
- Can I delegate authentication for a subset of users (in my case this will always be an entire organization) to another authentication provider (say Microsoft ADFS)?
Yes! Right now we only support OpenID Connect and OAuth1/OAuth2 delegation but more to come.
- Do you support SAML 2.0 clients?
Not yet, but there's an active design document with discussions on different implementation scenarios.
- Do you have a REST API which can be used to create / deactivate users?
Creation - absolutely! Deactivation is not yet available as an API but identity state is already implemented, so adding it is really just a few lines of code.
There are also endpoints for revoking all active sessions which logs out users immediately of one to all systems.
Does it support OAuth1 delegation. Could you point to the docs
The project for which I'm most interested in a solution like Ory Kratos is a multi-tenant SAAS, with a few hundred organizations. The organizations in general already have other systems that they use to keep track of employees, and so they want to be able to interface with our system to create and deactivate (or delete) users.
So it would suffice if we could host all organizations in one instance, and that we would still be able to directly expose Ory Kratos API's to our clients without them being able to see users in other organizations.
There be dragons.
(Disclosure: I work for FusionAuth.)
Funny story. We had a client doing a SAML integration using HTTP-redirect bindings. It worked when you turned off request signature verification (which is fine for testing, but is like using alg="none" for JWTs, a non-starter in production), but failed when that was turned on. We dug in with the client and another vendor, set up some test servers, and identified the bug[0]. Turns out that you can't canonicalize the signature's URL encoded form, because both uppercase and lowercase hex values are allowed, by the SAML spec.
Our open source SAML library[1] has been around for years and used by many clients in FusionAuth and our other projects. It'd never run into this particular edge case. It is a wild west out there in SAML land and it takes years to build a bulletproof implementation. Ory folks, if you can leverage an existing implementation rather than rolling your own, I'd highly advise that approach.
That is also to say nothing of the incoming privacy/cookie limitation changes that are coming in the next few years. This will unfortunately probably negatively affect SAML, which is not a specification that has evolved much. If this is of interest to you, I'd recommend the Federated Identity W3C community group[2].
That said, FusionAuth supports SAML in many forms[3]. SAML support varies across vendors and implementations, but other providers like Keycloak and IdentityServer do so as well.
0: https://github.com/FusionAuth/fusionauth-issues/issues/1496
1: https://github.com/FusionAuth/fusionauth-samlv2
2: https://www.w3.org/community/fed-id/
3: https://fusionauth.io/docs/v1/tech/core-concepts/integration...
> I found it hard to quickly determine whether Kratos can run completely
> self-hosted, or that there's always some connection to Ory / Ory Cloud services.
Ory Cloud is still in it's early phases and we have not been very good at communicating it well. Basically, we run Ory Kratos in Ory Cloud and it has full API and configuration and data compatibility with the version that is on GitHub! Our goal is to also allow users to easily switch from self-hosted to ory cloud and back - but it's still a bit of work until we get there.
If you just want to check our Ory Kratos and don't want to use the docker-compose command in the blog post, you can create an Ory Cloud account and use that instead of your local docker environment. That's basically the trade off you're making in a local environment. We have of course tons of plans for Ory Cloud but it's yet too early to share them with a broad audience.
We're currently focusing on gettin all of this much better communicated, and to make it easier to understand what the differences are. So totally get your confusion on it and can only say, we're working on making it better :) Hope this helped at least a little bit!
Heads up, I don't quite get this from your pricing page at all right now.. It says "First 900 free" and "First 100 free" without any indication of what those numbers mean.
> It says "First 900 free" and "First 100 free" without any indication of what those numbers mean.
Thank you, we'll clarify that! It means that we're giving the first 900 "start up" and 100 "growth" plans away for free for a year
Yes, I am the CTO @ Clerk, and we do have per-user pricing right now, however, that doesn't mean we like it. It's something we've struggled with - how do you make pricing scale in some way, while still being clear, while also being predictable. There's also value in being in-line with the status quo - when your numbers are priced competitively using the "industry standard (auth0)" scale.
Every method, I think, has it's issues, and it's something we would like to make as frictionless as possible in the decision making process. I imagine with a "per CPU/mem usage model", you will run into a lot of questions.. (how am i supposed to know how much CPU/mem you, as a cloud provider, uses?). I also don't necessarily think gcloud/aws/etc. are the bastion of clear pricing.
Per API call seems more predictable, but still not as clear as the "at a glance, MAU number" Do product managers know how many API calls your average user would use? Yes, auth is most often implemented by devs, but are they always the buyer?
I do think there's something better, and I like thinking about new options :) We don't have a clear plan to change from MAU right now, but I hope we get there. Love ory btw, been following it for quite some time!
I’ve done some research into Hydra: https://gruchalski.com/posts/2021-05-23-do-you-really-need-a....
I think you might want to try the API calls pricing model (a la S3) because as a dev I usually don't know how much resources I need. But I can estimate that if I have X user that login each day that makes Y API calls which translate to Z$ (with proper spamming protection of course).
It’s hard to use the correct terms when you have users signing up to user management as a service xD
If you are an app for schools and students, you might have 300k users in Sep-May, but 10k users in Jun-Aug.
Would you feel comfortable if the cost went down during the low traffic months to a lower band, based on the 10k users?
Or is that still a non-starter?
Because the vast majority do 1-2 API calls to login once, are considered active and then never login again during the month. But you still have to pay as if it was active for the whole month.
That is why per API call pricing (a la AWS S3) or resources based pricing (1 CPU) is the best.
I'm interested in how you allow folks to customize the login flows (probably because my employer, FusionAuth, offers a competitive product :) ). Is this UX customization solely through custom react components?
Is there any ability to customize the actual login sequence, like Azure ADB2C allows? For example: for install A, I want to ask for login, then password, then MFA. for install B, I want to ask for email domain first, then login and password.
All of Ory's Open Source software is unique in a way that we strictly follow domain-driven design. Solve one problem only, but solve it extremely well, and solve it in isolation. Ory Kratos (and other Ory Projects) are API only. The UI is up to you. You can use Ory for CLIs, fridges, TVs, native mobile apps, Java Server Pages, and React apps.
So, you're also free to choose the UX for your users with a very high degree of freedom - something we found very frustrating before we started working on Ory. Of course, there are some limitations (as always in software) but we try to focus them around security and not how we interpret that sign up flows should look like.
For those who just want something to work, we have templates one can use to get off the ground in a few minutes!
My only real pain points are the docs and the JS SDK - the docs can be rough depending on what you're looking at, and the SDK has no documentation at all. I get that it's automatically generated, but it's enough of a pain to figure out that I resorted to just making the HTTP requests myself.
If you do want to store users locally, you have some adapters you can use. They leave a lot of room for interpretation (or rather implementation), meaning that you will probably have to implement a lot of stuff from zero!
Ory Kratos is like the system behind the Google, Twitch, or Pipedrive profile management, so it has the database of users and it offers variety of user flows for e.g. updating sensitive information, adding WebAuthn 2FA, managing one's profile, and so on.
To conclude, you most likely will be able to combine NextAuth with Ory Kratos or Ory Hydra if it makes sense for your use case!
Also, authentication and authorization are core for an app. If we do authentication here, how does authorization work? Can I bring my own authorization like oso etc.
1. What do you do when a user with email "foo@example.org" has already signed up, and now is trying to sign up using Google with "foo@example.org"?
2. How do you ensure that a user can update sensitive information (e.g. their recovery email address, or linking additional "Sign in with" providers) while keeping a balance between security and user experience?
3. What if you now want to add biometric auth for native mobile apps, or 2FA?
The complexity in building your own is not starting with the first 10%. As your app and business grows, teams are faced with ever increasing requirements. Leaning on an established open source provider built by experts in the area just saves you so much time, headaches, and potential security oversights!
> What Db does Ory use? Should we set up our own.?
We support all prominent SQL systems - so PostgreSQL, MySQL, CockroachDB, SQLite, ... - and of course all cloud SQL vendors. You can also choose to run Ory in Ory Cloud, then we take care of all of this for you!
> Also, authentication and authorization are core for an app. If we do authentication here, how does authorization work? Can I bring my own authorization like oso etc.
Absolutely! We have a project for this also: https://github.com/ory/keto
Hope this clarifies your questions!
> The functionality provided for credentials based authentication is intentionally limited to discourage use of passwords due to the inherent security risks associated with them and the additional complexity associated with supporting usernames and passwords
I cannot disagree more. Using 3rd party auth has a lot of issues such as data privacy (requirement of stating that in your privacy/GDPR policy if you are in the EU), increased user support request when they cannot remember which auth provider they used, or the ever growing cases in which Facebook/Google/Whatnot decide to close someones account without possibility to appeal and effectively shutting them out of your App. Or the risk that if Google/FB/Github might not like your webapp, they can disable auth for your users with the flip of a switch. Me personally, I avoid 3rd party auth for those reasons alltogether.
It's also important to note that almost no 3rd party providers offer the ability to require 2FA as part of their flows. So if you need 2FA and similar, you'll end up with your own system again. And you'll probably use passwords, because proving that you own two things - eg email and device - is not a second factor. If someone steals your laptop (something you no longer own :D ) it's just one factor!
I'm always hesitant to use third party Auth for fear that some bug in our app would generate otps and I won't be able to fix that in an emergency because of a lack of familiarity/access to source code/database
We have on the list to add a section about using Next's new middleware feature to protect API routes. Is that something you'd be interested in?
By the way people usually disclaim upfront on HN (see FusionAuth folks here) when they are involved in a project. Seems like you are the "CTO at Clerk". Frankly it's dishonest to talk bad about open source without claims to back it up while also being in a competitive space and plugging your solution in their "Show HN" moment.
tl;dr no thanks I'll look somewhere else...
Ory has been around for awhile, they're quite the gorilla in the identity space - It's a set of very large, and very impressive products that work well together. It is extremely powerful, flexible, and can handle almost any use case. I'd define "lighter" as being more opinionated in it's approach with fewer options - as a result it's less powerful and flexible. Also, w/ open source, comes setting up your own infra (even if that's now just throwing it in a cloud), which I'd consider "heavier". Imo, these terms don't mean something is worse than something else, just a fit for a different use case.