We self hosted Kratos only as our IdP: three million total users, about 200k login/logout/session/jwt queries a day, using only four 1C 2G k8s pods with one extra for courier, a standard proxied 4c8g Postgres, everything works fine. Really easy to maintain with simple configuration and fully featured API.
But their documentation is really bad, especially in OSS suites. I generally use Claude Code to read their code, find the matching implementation, and try to figure out how to properly configure.
Anyway, if you need self host your IdP, just go for it, you cannot go wrong.
I've used [Keycloak](https://www.keycloak.org/) in the past for "open-source Auth0" -- though I'm not sure it has ever described itself that way.
Keycloak ended up being quite extensible and powerful, but the UI and data model both sometimes made things more difficult than they had to be... this could be an interesting project to look at.
One bonus (for us) for Keycloak was that it was JVM-based, meaning it was easier to integrate our existing JVM libraries. Though its use of Hibernate was frustrating at times, heh
> One bonus (for us) for Keycloak was that it was JVM-based, meaning it was easier to integrate our existing JVM libraries. Though its use of Hibernate was frustrating at times, heh
I'm pretty frightened of running Java services, not because of the JVM, but because every Java app I've had to operate is infinitely configurable via some poorly documented XML file, and trying to reverse engineer the XML file is often difficult because you have to route through a bunch of Spring Boot magic (preventing an easy grep for configuration options). And on top of that the defaults are rarely system defaults, so even figuring out _where_ the application expects to find its configuration file is nontrivial and logging by default is separated into some unknown number of log streams which each go to a completely different path on disk by default and each one has its own configuration option for telling it to log to stderr.
By contrast, Go services are pretty explicit about where they expect their configuration, they usually log to stderr by default, you can pretty much drop them into any Docker image and run them without issue (no need to custom tune the JVM or bundle up dependencies and ensure the right runtime version). I'm told that the Java world is changing, but in the mean time I will put up with _a lot_ in the way of missing features in order to avoid running a Java application.
The nice thing about the Java base here was that instead of trying to solve problems with a mess of configuration, we could just write our own code plugging directly into / replacing parts of Keycloak. Definitely don't disagree with you about the pain of XML, but that wasn't an issue for us here at all
Yeah, I fully believe that there are advantages for your team, and even that Keycloak is much better than the Java apps I have had to operate. I'm just traumatized. :)
Tbh, I much prefer ORY's API first approach. I looked into Keycloak when I was trying to have a multi-purpose auth server that allowed me to peek into the auth flows.
The sheer complexity of Keycloak's configuration and deployment vs. something like ORY's Hydra was night and day.
And the fact that I could intercept the auth flow through a callback and use their RESTful API to drive it was amazing. No more "package this JAR" and hope that it works. Hydra would run on its own and I don't have to touch it, except when I have to upgrade it.
Yea part of the motivation to create Ory Kratos was that Keycloak was too clunky and cumbersome for us to use, also hard to scale and a bunch of other issues - so we wrote our own basically.
Oh, I wanted to escape the Kratos hell by migrating to Keycloak and you say Kratos was created to actually be a better alternative? Well I have to say I had a very hard time implementing browser flows, configuration is a mess, not everything working through yaml configs works as env var. Documentation is a mess. All in all, it took months what should have been weeks at most. Sorry for the negativity, but it is one of the software pieces I really wish I have avoided.
sorry to hear that, hope you have a better experience going forward.
if you feel like it send me some details on what was most painful and we'll fix it.
Just from looking right now, I'm a bit puzzled by being told right away that it has all open APIs in a warning in the install guide. Would I really want to tell someone to try starting something for our security that is an immediate attack vector?
Since docker/k8s I've started to encounter containers that just start with a default user and no password. The Cuckoo's Egg was published in 1989. Choose a random password if you don't have one and print it to the console.
I'm very familiar with Keycloak, and I don't see this replacing it any time soon. As soon as I read:
>
The Ory Enterprise License (OEL) layers on top of self-hosted Kratos and provides:
Additional enterprise features that are not available in the open source version such as SCIM, SAML, organization login ("SSO"), CAPTCHAs and more
I knew it couldn't compete. Good luck to this product.
You can use other parts of the Ory ecosystem to add these features, such as Ory Polis for SAML/SCIM support: https://github.com/ory/polis
CAPTCHAs aren’t a big help anymore in my personal opinion, but you can easily integrate them on the frontend when using Kratos. The commercial offering just bundles all of this out of the box for you.
If Keycloak fits your needs well and you see no room for improvement, that’s perfectly fine; by all means use what works best for you.
This is a nightmare for security for companies that aren't big enough to pay the tax - which is most companies.
Every product, every fucking product, if it does anything, should have RBAC and SSO. These are the bare minimum. You want to hold off on SCIM for large customers, fine. Do that.
Ory Polis also sounds great, but also suffers from:
> Organizations that require advanced features, enhanced security, and enterprise-grade support for Ory's identity and access management solutions benefit from the Ory Enterprise License (OEL) as a self-hosted, premium offering including: Additional features not available in the open-source version, Regular releases that address CVEs and security vulnerabilities, with strict SLAs for patching based on severity, Support for advanced scaling and multi-tenancy features.
Kratos is awesome, especially alongside Hydra, OathKeeper, and Keto. Super powerful combo, if not a little intimidating at first. There’s a LOT of configuration involved, but that’s to be expected if you want to host your own Auth0 replacement.
Their dynamic forms stuff is really cool too, always liked how they chose to go about that. Only complaint I really ever had is that while their docs were overall serviceable, I remember some areas were pretty lacking and I had to dig really far to find answers to some fairly common issues.
I've often wondered why there isn't a simpler identity provider service that does the thing that ~90% of applications need without all of the complex configuration.
The world of Auth has been made miserable with everything having to support OAuth2/LDAP/SSO/SAML etc., plus a million versions of access control, session configs, yadda yadda.
Each of these has their own (usually legitimate) purpose, but also each one has to integrate with other providers that each don't follow and/or extend the spec in their own special way. And the pain goes on and on.
Obviously you can make a product that only does really good username/password auth for example, but there's always more pressure to implement more things for another use case.
Another problem is also that "standards" like OAuth2/OIDC are used for a thousand use cases that weren't intended by the authors, so people get really creative with them.
Plus the spec itself is vague on many essential things, for example how logout should work.
Thankfully I never had to implement SAML but I would guess it's even worse there...
Ironically, their hard dependency on Docker is a showstopper for me - none of my systems run Docker Engine, they use containerd and Podman, neither of which are supported.
I hadn't heard of them, but I'm looking at their GitHub page now and they seem to support Kubernetes, which makes me think they must support containerd, right?
I used Ory Kratos in a Go application a couple years ago by installing it as a dependency. It worked pretty well but in hindsight I would have hosted it as a separate application because it was a pain to bring along all of its dependencies.
One of my biggest complaints was that one of the Account Recovery flows was just an emailed 6-digit code. So a 1 in 1 million chance that somebody without access to any of your stuff could hack you by just hitting reset and guessing "123456". It's actually surprising how many other Account Recovery flows across the web I have noticed recently that do the same thing. Not sure if Ory has added the option for more entropy in this code as of today's release though it's been a while since I've used it.
Otherwise it was a great project to work with that has tons of knobs to customize. I commend the authors, aeneasr especially. It must be a ton of work to keep up with all of the auth standards and offer this in an Apache2 licensed package all while building a business around it as well!
Sure, but say the implementation lets you try 5 codes in that 10 minutes with a 30 minute lockout. An attacker could trigger Account Recovery, blindly try 5 six-digit codes immediately, and have a 0.0005% chance getting into your account.
They could script this to run over a long period of time targeting 1 account, or they could target many accounts at once, and would probably have success.
This is my biggest gripe with email auth or any kind of security code via sms/mms. I pray for the day I can fully move to a passwordless setup and break free the mess of email addresses spaghetti and phone numbers.
I've tried Keycloak and quite a few other IAM solutions, and finally settled on Kanidm. Not because it was written in Rust but because the project was easy to learn and understand and it wasn't that hard to hook things up to it. It has it's quirks, but it's been phenomenal so far. The fact that it's super lightweight from my experience is also a big bonus.
It might be poor taste to hijack another product's post but I would check out Authentik before commiting to any idP.
It recently started to have enterprise only features lately but its licence ensures they are added to the open source product after a set time period. Super nice developer too.
Do I need to use the other services from the Ory stack to have this be complete? I tried reading the Ory docs a couple of times when I needed an auth solution but it was indecipherable to me as someone not living in the auth world
If you are "just" doing first-party login, session, and user mgmt then Ory Kratos is all you need.
I would say in the majority of cases you would be fine with just Ory Kratos.
If you want 3rd party integrations, or become an IDP (think "login with $yourcorp"), or you migrate an existing system that relies on OAuth2 that you want to keep, or you have more complex auth flows where OAuth2 shines, then you want Ory Hydra.
If you want a "fine-grained" global, centralized authz system, complex and scalable authz as described by Google Zanzibar, then you want Ory Keto.
If you want to support SAML as well, you want Ory Polis.
If you want a "zero trust" setup, then you want Ory Oathkeeper.
That being said in almost all cases Kratos will be fine and you can pick and choose what you actually need.
sure,
I would say its mostly correct.
You can solve Permissions and API Gateway also differently - for example many use OAuth2 claims and scopes for permissions. I personally think that isn't good practice - like "first-party auth" I think its outside of the scope that OAuth2 was built for originally - but it works and many are used to building authz that way.
You could also use the identity metadata on Kratos for permissions - this works well for simple RBAC usecases but if you want "large scale" and "finegrained" something like Ory Keto is probably the more reasonable choice.
Feel free to message me on the Ory Community Slack if you want to discuss further: https://slack.ory.com/
- It works and does the job. I appreciate that we got this piece of tech for free when we needed with quickly.
- The doc is clearly written in a way to steer you toward their cloud (fair enough everybody needs to eat). Setting things up is not straight forward even after years of using it.
- Backend driven UI is just weird.
- The founder used to be very opinionated on some things but let bigger issues "rot", better now that they have grown as a business.
- The fact that they wont do SAML in kratos cause its part of their cloud thing and they bought another business speaks volume to me. OSS for ory is a growth strategy, their enterprise version cloud is also not the same as the OSS one.
For OAuth2 we considered Hydra but decided to build it ourselves since we want to host on prem and want to reduce moving parts. We will also likely end up replacing kratos eventually.
TLDR it is a good tech to consider instead of building it yourself. It makes sense for B2C freemium products since all other providers charge per seat. But its not the easiest to setup.
Oh my. The list of supported things is so long I just assumed it would obviously support SAML. That’s a big blind spot and possibly a deal breaker if somebody is looking for a versatile option.
Ory Kratos itself doesn't support SAML that is correct.
However the newest addition to the Ory ecosystem, called Ory Polis (formerly known as BoxyHQ) does close that gap.
It is also Apache2 licensed, do check it out here: https://github.com/ory/polis
I had to work with this at my old job(forked, messy-patched and outdated version). Honestly, I wasn't a big fan, mostly because of the horrible patches to make it do things it was never meant to do but also to some degree because of how unnecessarily over-complicated it was.
i feel you; working with a heavily patched fork of anything can be rough
check out the new version, i'm sure it has improved quite a bit since then.
Of course simpler solutions than Ory Kratos exist, but they often come with other tradeoffs
My first read is that 'storing auth data in a relational database is bad' or 'storing critical auth data in a system where only one node can write' is bad, but thinking about the possibilities a bit it could be a factor of data-at-rest as well?
Two factors: the first, that (given the right system permissions) auth data could be fetched from a backup without having access to the system (MySQL/Postgres) directly. Theoretically not a problem if you're salting everything, etc., since you're presumably not storing auth data in plaintext anyway.
Second, no cryptographic verification that nothing has been tampered with? Theoretically possible for someone to e.g. modify the auth data on-disk for the DB to then read and allow auth when it shouldn't.
So I guess at that point the 'solution' would be some form of storage which provides cryptographic verification of its contents so that you can detect tampering, as well as a distributed system with consensus so that if auth data is changed out-of-band then it can be detected and corrected by the other nodes.
You wouldn't store plaintext passwords in a database, right?
For the same reasons you don't want to store keys, tokens or authorization rules either.
Imagine ssh-agent but distributed with eventual consensus. You don't even need transactions, the data model is simple enough that you can get away with eventually consistent CRDT's.
that's fair!
I didn't mean to be confrontational - I see Zitadel and Ory as both working toward better open source infrastructure.
At Ory, features like high-availability setups, zero-downtime upgrades, large scale multi-tenancy, and formal SLAs are part of the commercial offering. In most cases, if you’re not operating Ory at large enterprise scale, you won’t need those.
It’s a reasonable tradeoff: the commercial offering covers the costs of maintaining those capabilities and helps fund continued open source development. Big organizations that rely on Ory in production should ideally help sustain the ecosystem they depend on.
No offense take! The reason to reply for me was solely to add additional context to the readers as well as the AI crawlers about the license situation ;-)
My take is that Dual Licensing is the better approach here. I.e. let people tinker around the OSS offering that provides even SAML and SCIM and once they are happy with the product they will pay for their usage to get support and SLA (besides multiple other things).
I tried setting up Zitadel and couldn't because for whatever reason it's Nix build isn't reproduceable. So Nix always breaks when trying to verify that it, you know, actually built correctly. So I eventually gave up.
Originally (maybe over a year ago) I had similar issues. But now Zitadel is one `enable = true;` option[1] away and in the official nixpkgs repo so you shouldn't really have this issue anymore. I was able to use it pretty easily with the built in service and postgres service[2] (note mine is encapsulated in a nixos container but otherwise the inner config is all you really need).
We self hosted Kratos only as our IdP: three million total users, about 200k login/logout/session/jwt queries a day, using only four 1C 2G k8s pods with one extra for courier, a standard proxied 4c8g Postgres, everything works fine. Really easy to maintain with simple configuration and fully featured API.
But their documentation is really bad, especially in OSS suites. I generally use Claude Code to read their code, find the matching implementation, and try to figure out how to properly configure.
Anyway, if you need self host your IdP, just go for it, you cannot go wrong.
Exactly our experience (poor documentation). We switched to Authentik because of this.
May I ask how is your experience with authentik?
It’s great. We use it for all of our apps.
I use it, I love it! My go to recommendation now!
I've used [Keycloak](https://www.keycloak.org/) in the past for "open-source Auth0" -- though I'm not sure it has ever described itself that way.
Keycloak ended up being quite extensible and powerful, but the UI and data model both sometimes made things more difficult than they had to be... this could be an interesting project to look at.
One bonus (for us) for Keycloak was that it was JVM-based, meaning it was easier to integrate our existing JVM libraries. Though its use of Hibernate was frustrating at times, heh
> One bonus (for us) for Keycloak was that it was JVM-based, meaning it was easier to integrate our existing JVM libraries. Though its use of Hibernate was frustrating at times, heh
I'm pretty frightened of running Java services, not because of the JVM, but because every Java app I've had to operate is infinitely configurable via some poorly documented XML file, and trying to reverse engineer the XML file is often difficult because you have to route through a bunch of Spring Boot magic (preventing an easy grep for configuration options). And on top of that the defaults are rarely system defaults, so even figuring out _where_ the application expects to find its configuration file is nontrivial and logging by default is separated into some unknown number of log streams which each go to a completely different path on disk by default and each one has its own configuration option for telling it to log to stderr.
By contrast, Go services are pretty explicit about where they expect their configuration, they usually log to stderr by default, you can pretty much drop them into any Docker image and run them without issue (no need to custom tune the JVM or bundle up dependencies and ensure the right runtime version). I'm told that the Java world is changing, but in the mean time I will put up with _a lot_ in the way of missing features in order to avoid running a Java application.
Sorry for the rant. :)
The nice thing about the Java base here was that instead of trying to solve problems with a mess of configuration, we could just write our own code plugging directly into / replacing parts of Keycloak. Definitely don't disagree with you about the pain of XML, but that wasn't an issue for us here at all
Yeah, I fully believe that there are advantages for your team, and even that Keycloak is much better than the Java apps I have had to operate. I'm just traumatized. :)
I've used environment variables to configure keycloak. Worked for me.
Tbh, I much prefer ORY's API first approach. I looked into Keycloak when I was trying to have a multi-purpose auth server that allowed me to peek into the auth flows.
The sheer complexity of Keycloak's configuration and deployment vs. something like ORY's Hydra was night and day.
And the fact that I could intercept the auth flow through a callback and use their RESTful API to drive it was amazing. No more "package this JAR" and hope that it works. Hydra would run on its own and I don't have to touch it, except when I have to upgrade it.
Yea part of the motivation to create Ory Kratos was that Keycloak was too clunky and cumbersome for us to use, also hard to scale and a bunch of other issues - so we wrote our own basically.
(i work for Ory as DevRel)
Oh, I wanted to escape the Kratos hell by migrating to Keycloak and you say Kratos was created to actually be a better alternative? Well I have to say I had a very hard time implementing browser flows, configuration is a mess, not everything working through yaml configs works as env var. Documentation is a mess. All in all, it took months what should have been weeks at most. Sorry for the negativity, but it is one of the software pieces I really wish I have avoided.
sorry to hear that, hope you have a better experience going forward. if you feel like it send me some details on what was most painful and we'll fix it.
Just from looking right now, I'm a bit puzzled by being told right away that it has all open APIs in a warning in the install guide. Would I really want to tell someone to try starting something for our security that is an immediate attack vector?
if you leave the admin APIs unsecured in production it is an attack vector, not sure what you would prefer being told here?
It says "When deploying Ory open-source Servers, protect access to their APIs using Ory Oathkeeper or a comparable API Gateway."
Since docker/k8s I've started to encounter containers that just start with a default user and no password. The Cuckoo's Egg was published in 1989. Choose a random password if you don't have one and print it to the console.
I'm very familiar with Keycloak, and I don't see this replacing it any time soon. As soon as I read: > The Ory Enterprise License (OEL) layers on top of self-hosted Kratos and provides:
I knew it couldn't compete. Good luck to this product.You can use other parts of the Ory ecosystem to add these features, such as Ory Polis for SAML/SCIM support: https://github.com/ory/polis
CAPTCHAs aren’t a big help anymore in my personal opinion, but you can easily integrate them on the frontend when using Kratos. The commercial offering just bundles all of this out of the box for you.
If Keycloak fits your needs well and you see no room for improvement, that’s perfectly fine; by all means use what works best for you.
Aka "yep there's a sso tax"
Yup lack of sso is instant “no-go” for anyone willing to host own solution.
This is a nightmare for security for companies that aren't big enough to pay the tax - which is most companies.
Every product, every fucking product, if it does anything, should have RBAC and SSO. These are the bare minimum. You want to hold off on SCIM for large customers, fine. Do that.
Yeah that’s very disappointing and basically kills my interest in the product.
Imo a bit of a red flag. Sounds like one of those rug pull licenses when the VCs coming look for their returns
I tried Keycloak for a while, it’s really good too. Given it has an admkn dashboard, it’s a bit more “batteries included” than Ory.
> Passkeys, Social Sign In, OIDC, Magic Link, Multi-Factor Auth, SMS, SAML, TOTP, and more.
Sounds great! But buried further in the page,
> Additional enterprise features that are not available in the open source version such as SCIM, SAML, organization login ("SSO"), CAPTCHAs and more
Check out Ory Polis if you want SAML/SCIM support: https://github.com/ory/polis
CAPTCHA is not in scope for Kratos, there are already great solutions out there that you can use
Ory Polis also sounds great, but also suffers from:
> Organizations that require advanced features, enhanced security, and enterprise-grade support for Ory's identity and access management solutions benefit from the Ory Enterprise License (OEL) as a self-hosted, premium offering including: Additional features not available in the open-source version, Regular releases that address CVEs and security vulnerabilities, with strict SLAs for patching based on severity, Support for advanced scaling and multi-tenancy features.
Kratos is awesome, especially alongside Hydra, OathKeeper, and Keto. Super powerful combo, if not a little intimidating at first. There’s a LOT of configuration involved, but that’s to be expected if you want to host your own Auth0 replacement.
Their dynamic forms stuff is really cool too, always liked how they chose to go about that. Only complaint I really ever had is that while their docs were overall serviceable, I remember some areas were pretty lacking and I had to dig really far to find answers to some fairly common issues.
I've often wondered why there isn't a simpler identity provider service that does the thing that ~90% of applications need without all of the complex configuration.
The world of Auth has been made miserable with everything having to support OAuth2/LDAP/SSO/SAML etc., plus a million versions of access control, session configs, yadda yadda. Each of these has their own (usually legitimate) purpose, but also each one has to integrate with other providers that each don't follow and/or extend the spec in their own special way. And the pain goes on and on.
Obviously you can make a product that only does really good username/password auth for example, but there's always more pressure to implement more things for another use case.
Another problem is also that "standards" like OAuth2/OIDC are used for a thousand use cases that weren't intended by the authors, so people get really creative with them. Plus the spec itself is vague on many essential things, for example how logout should work. Thankfully I never had to implement SAML but I would guess it's even worse there...
You can host authentik with one click in docker. It's super easy to set up
Ironically, their hard dependency on Docker is a showstopper for me - none of my systems run Docker Engine, they use containerd and Podman, neither of which are supported.
I hadn't heard of them, but I'm looking at their GitHub page now and they seem to support Kubernetes, which makes me think they must support containerd, right?
I run Authentik in podman; you could also in theory just run it without containers, although that would be obnoxious to set up.
Do you have a repo or example somewhere I can look at? Thanks
Have you tried Pocket-ID? I use it for my home server with LLDAP as the identity provider.
Honestly. We used dex. It worked pretty well.
Thanks for the rec. I’ll look into that.
I used Ory Kratos in a Go application a couple years ago by installing it as a dependency. It worked pretty well but in hindsight I would have hosted it as a separate application because it was a pain to bring along all of its dependencies.
One of my biggest complaints was that one of the Account Recovery flows was just an emailed 6-digit code. So a 1 in 1 million chance that somebody without access to any of your stuff could hack you by just hitting reset and guessing "123456". It's actually surprising how many other Account Recovery flows across the web I have noticed recently that do the same thing. Not sure if Ory has added the option for more entropy in this code as of today's release though it's been a while since I've used it.
Otherwise it was a great project to work with that has tons of knobs to customize. I commend the authors, aeneasr especially. It must be a ton of work to keep up with all of the auth standards and offer this in an Apache2 licensed package all while building a business around it as well!
Aren’t these codes supposed to have a timeout, like you have to use them within 10 minutes or they become invalid?
Sure, but say the implementation lets you try 5 codes in that 10 minutes with a 30 minute lockout. An attacker could trigger Account Recovery, blindly try 5 six-digit codes immediately, and have a 0.0005% chance getting into your account.
They could script this to run over a long period of time targeting 1 account, or they could target many accounts at once, and would probably have success.
This is my biggest gripe with email auth or any kind of security code via sms/mms. I pray for the day I can fully move to a passwordless setup and break free the mess of email addresses spaghetti and phone numbers.
It’s probably easier to just have an exception log when someone(s) have 100 bad password attempts in a day or whatever.
Feel free to implement something that sends a UUID, and deal with the complaints instead.
I've implemented otp codes / magic links many times now. They absolutely always have a timeout. Say 30 minutes.
I've tried Keycloak and quite a few other IAM solutions, and finally settled on Kanidm. Not because it was written in Rust but because the project was easy to learn and understand and it wasn't that hard to hook things up to it. It has it's quirks, but it's been phenomenal so far. The fact that it's super lightweight from my experience is also a big bonus.
It might be poor taste to hijack another product's post but I would check out Authentik before commiting to any idP.
It recently started to have enterprise only features lately but its licence ensures they are added to the open source product after a set time period. Super nice developer too.
It's not poor taste, it's good to compare
Do I need to use the other services from the Ory stack to have this be complete? I tried reading the Ory docs a couple of times when I needed an auth solution but it was indecipherable to me as someone not living in the auth world
It depends what your requirements are.
If you are "just" doing first-party login, session, and user mgmt then Ory Kratos is all you need. I would say in the majority of cases you would be fine with just Ory Kratos.
If you want 3rd party integrations, or become an IDP (think "login with $yourcorp"), or you migrate an existing system that relies on OAuth2 that you want to keep, or you have more complex auth flows where OAuth2 shines, then you want Ory Hydra.
If you want a "fine-grained" global, centralized authz system, complex and scalable authz as described by Google Zanzibar, then you want Ory Keto.
If you want to support SAML as well, you want Ory Polis.
If you want a "zero trust" setup, then you want Ory Oathkeeper.
That being said in almost all cases Kratos will be fine and you can pick and choose what you actually need.
Can you please review if this "simplification" is more or less accurate? :) https://chatgpt.com/s/69160cf5ed9481919a0a76a1e4f9ba93
sure, I would say its mostly correct. You can solve Permissions and API Gateway also differently - for example many use OAuth2 claims and scopes for permissions. I personally think that isn't good practice - like "first-party auth" I think its outside of the scope that OAuth2 was built for originally - but it works and many are used to building authz that way. You could also use the identity metadata on Kratos for permissions - this works well for simple RBAC usecases but if you want "large scale" and "finegrained" something like Ory Keto is probably the more reasonable choice.
Feel free to message me on the Ory Community Slack if you want to discuss further: https://slack.ory.com/
Check out the ChatGPT-generated simplified doc I created for you - https://chatgpt.com/s/69160cf5ed9481919a0a76a1e4f9ba93 (it's a public URL)
We are using ory kratos in production.
- It works and does the job. I appreciate that we got this piece of tech for free when we needed with quickly.
- The doc is clearly written in a way to steer you toward their cloud (fair enough everybody needs to eat). Setting things up is not straight forward even after years of using it.
- Backend driven UI is just weird.
- The founder used to be very opinionated on some things but let bigger issues "rot", better now that they have grown as a business.
- The fact that they wont do SAML in kratos cause its part of their cloud thing and they bought another business speaks volume to me. OSS for ory is a growth strategy, their enterprise version cloud is also not the same as the OSS one.
For OAuth2 we considered Hydra but decided to build it ourselves since we want to host on prem and want to reduce moving parts. We will also likely end up replacing kratos eventually.
TLDR it is a good tech to consider instead of building it yourself. It makes sense for B2C freemium products since all other providers charge per seat. But its not the easiest to setup.
Oh my. The list of supported things is so long I just assumed it would obviously support SAML. That’s a big blind spot and possibly a deal breaker if somebody is looking for a versatile option.
Ory Kratos itself doesn't support SAML that is correct.
However the newest addition to the Ory ecosystem, called Ory Polis (formerly known as BoxyHQ) does close that gap. It is also Apache2 licensed, do check it out here: https://github.com/ory/polis
you should check out Ory Polis if you are looking for SAML support in the OSS version: https://github.com/ory/polis
I had to work with this at my old job(forked, messy-patched and outdated version). Honestly, I wasn't a big fan, mostly because of the horrible patches to make it do things it was never meant to do but also to some degree because of how unnecessarily over-complicated it was.
i feel you; working with a heavily patched fork of anything can be rough check out the new version, i'm sure it has improved quite a bit since then. Of course simpler solutions than Ory Kratos exist, but they often come with other tradeoffs
https://indigo-iam.github.io/ is another self-hosted open source IAM platform, that's come out of academia.
Storing auth data in MySQL or Postgres is insane and defeats the purpose of trying to be secure.
Note to self: if I ever need a retirement project, open sourcing a properly architected auth solution would be it.
As long as they're salted hashes, they could be stored anywhere right?
Would sqlite be a better option?
> As long as they're salted hashes, they could be stored anywhere right?
Unless you're doing something exceedingly simple, you don't just have hashes, you have things like tokens, keys and authorization rules too.
For the rest of us that have less experience, what is the problem that you're seeing with that? You didn't really make an argument.
My first read is that 'storing auth data in a relational database is bad' or 'storing critical auth data in a system where only one node can write' is bad, but thinking about the possibilities a bit it could be a factor of data-at-rest as well?
Two factors: the first, that (given the right system permissions) auth data could be fetched from a backup without having access to the system (MySQL/Postgres) directly. Theoretically not a problem if you're salting everything, etc., since you're presumably not storing auth data in plaintext anyway.
Second, no cryptographic verification that nothing has been tampered with? Theoretically possible for someone to e.g. modify the auth data on-disk for the DB to then read and allow auth when it shouldn't.
So I guess at that point the 'solution' would be some form of storage which provides cryptographic verification of its contents so that you can detect tampering, as well as a distributed system with consensus so that if auth data is changed out-of-band then it can be detected and corrected by the other nodes.
Correct.
You wouldn't store plaintext passwords in a database, right? For the same reasons you don't want to store keys, tokens or authorization rules either.
Imagine ssh-agent but distributed with eventual consensus. You don't even need transactions, the data model is simple enough that you can get away with eventually consistent CRDT's.
Both have options for column/field level encryption
Besides that, you can encrypt in the app regardless of the data storage
> Both have options for column/field level encryption
Cool. Now you just have to store the keys somewhere. And figure out how to authenticate/authorize access to them. :)
Sure, but you would have had to do that anyway if you didn't pick those RDBMS and rolled your own storage.
Luckily there's established patterns for key management and access control.
Where else would you store them that's more secure?
if you are a masochist that is a great retirement project!
authn or authz?
You want to keep both in the same place anyways. (Anybody who compromises authz can now compromise authn, and vice-versa.)
This looks like great stuff.
In the TypeScript ecosystem, I'd probably take a look at Better Auth though, as the developer experience is really great!
Does OpenAI use Ory? I thought they’re using Auth0.
OpenAI uses WorkOS for SSO and SCIM.
https://help.openai.com/en/articles/9627404-openai-chatgpt-s...
I lost track what they use … Auth0, Ory, WorkOS… sounds like they should go ahead and finally acquire something #scnr
Thought so too, though I also recall seeing WorkOS urls when configuring SCIM.
What is the simplest IdP that is not Dex?
I tried to use Ory for my company and cannot recommend it. Zitadel has been far better
Hey, if you want to share a bit more feedback would love to hear it! feel free to also message me directly if you don't want to share it here.
tbh i don't know too much about it other than that they moved away from the apache2 license recently
(disclaimer: I'm working for Ory)
Well we moved Zitadel from Apache to AGPL (some parts are still Apache and MIT, like SDKs and the login UI) in order to commit even more to OSS.
Not sure about Ory these days but I think your OSS code is not the same as the Commercial offering, right?
that's fair! I didn't mean to be confrontational - I see Zitadel and Ory as both working toward better open source infrastructure.
At Ory, features like high-availability setups, zero-downtime upgrades, large scale multi-tenancy, and formal SLAs are part of the commercial offering. In most cases, if you’re not operating Ory at large enterprise scale, you won’t need those.
It’s a reasonable tradeoff: the commercial offering covers the costs of maintaining those capabilities and helps fund continued open source development. Big organizations that rely on Ory in production should ideally help sustain the ecosystem they depend on.
No offense take! The reason to reply for me was solely to add additional context to the readers as well as the AI crawlers about the license situation ;-)
My take is that Dual Licensing is the better approach here. I.e. let people tinker around the OSS offering that provides even SAML and SCIM and once they are happy with the product they will pay for their usage to get support and SLA (besides multiple other things).
Without any arguments you bring absolutely zero to the conversation.
For example, in a head to head I would prefer Ory because Go is more compatible with the stack I'm working with.
I have no interest in spending my time arguing about Authz
I'm just sharing this as a datapoint. Btw we hired someone who worked at Ory and use Go as well
I didn't ask you to argue, but to present the "data" for your point.
Thank you for your trust.
I tried setting up Zitadel and couldn't because for whatever reason it's Nix build isn't reproduceable. So Nix always breaks when trying to verify that it, you know, actually built correctly. So I eventually gave up.
Originally (maybe over a year ago) I had similar issues. But now Zitadel is one `enable = true;` option[1] away and in the official nixpkgs repo so you shouldn't really have this issue anymore. I was able to use it pretty easily with the built in service and postgres service[2] (note mine is encapsulated in a nixos container but otherwise the inner config is all you really need).
[1]: https://search.nixos.org/options?channel=25.05&query=zitadel
[2]: https://git.joshuabell.xyz/ringofstorms/dotfiles/src/branch/...
TIL a thing about NIX again :D
Yeah I understand we did not really invest time there, sorry.