Show HN: Ory Kratos – Open-source identity server written in Go | Hacker News Reader

Show HN: Ory Kratos – Open-source identity server written in Go

github.com

290 pointsnottennis65 comments

I learned so much about AuthN and AuthZ from reading Ory code and docs.

Sometimes it seems like Ory is the only web auth stuff on the internet that’s intended for you to understand how the whole system works, rather than telling you just enough to get you to use/buy their proprietary software (Auth0, Okta, etc).

I read a few books as well but they were extremely poorly done.

I eventually also read the entire OpenId Connect spec as well, which was enlightening.

I’d love to hear of other good resources - I am happy to pay for good stuff as long as it’s mot selling me service.

Thank you!

That is so great to hear! We are in the midst of refactoring the documentation structure for different audiences: people who want to try it out quickly, those who want in depth understanding (like you), code contributors, non-dev

It’s a long journey! If you ever see some of our docs again and feel that it has lost it’s way please reach out; It’s very important to us to not only show how the product works but also why :)

As I've opined here [1] I think OIDC is not a good example for an authentication protocol. As you are already into spec reading, you could take a look how SSH and TLS 1.3 (especially mutually authenticated TLS) handle the same topic. (All available freely as IETF RFCs.) And if you're interested in the cryptography, your can't go wrong with Cryptography Engineering (ISBN: 978-0470474242) by Ferguson, Schneier and Kohno.

[1] https://news.ycombinator.com/item?id=31259826

Open source documentation & tools are Okta/Auth0's biggest competitors :)

I find the documentation from Okta snd Auth0 pretty solid for understanding basic concepts of OpenID and Oauth.

Same experience for me too. I learned a lot, and integrating OAuth into a platform was pretty painless, including importing and managing users.

It was the first time I felt like I can wrangle the OAuth spec and implementation, and really understand all the ways in which things can go wrong without proper care and expertise into how an OAuth server can be attacked, and how to mitigate those issues the right way.

I'm also a huge fan of Keycloak for the same reason. It's been a while since I've looked at the Ory suite, but at least a year or two ago Keycloak was still the much more mature (and still fully OSS) product.

Either way, reading the Oauth2 and OIDC specs are probably the best way to get a really solid understanding of modern standardized authn and how to start thinking about authz.

https://openid.net/specs/openid-connect-discovery-1_0.html#P...

https://openid.net/specs/openid-connect-discovery-1_0.html#R...

Keycloak: Open-Source Identity and Access Management

https://news.ycombinator.com/item?id=31258469

and a couple lighter-weight projects to bookmark for myself:

Caddy Security https://news.ycombinator.com/item?id=31258469#31259369

GoTrue https://news.ycombinator.com/item?id=29392517#29399741

and a brief discussion of SCIM (Cross-domain Identity), including a Keycloak v16 extension:

https://news.ycombinator.com/item?id=31408059#31413662

In the .NET world, while no longer free (still is open source), there is https://duendesoftware.com/.

The folks behind the company and libraries know what they're doing.

It's tiring to see this discussion topic pop up again and again and again, but: the Duende software is decidedly not open source. You can read the code, but that's it. They don't seem to be making such claims themselves either.

https://github.com/DuendeSoftware/IdentityServer/blob/main/L... does not seem to square with any definition of "open source" I'm familiar with, and that goes double for having an in-repo file that just says "read this unversioned pdf on some other site"

>(still is open source)

I think https://en.wikipedia.org/wiki/Source-available_software is more accurate

see https://duendesoftware.com/license/identityserver.pdf (as pointed by https://github.com/DuendeSoftware/IdentityServer/blob/main/L... ) for their actual license.

One of the co-maintainers here. Ory Kratos has been in development since 2018 and is finally out of beta! If you have any questions about the project, tech, flows, or Ory as a whole I’m here to help :)

Would it be possible to migrate from IdentityServer4 & ASP.NET Identity Core? I currently have a SaaS running those 2 and would love to eventually migrate all users to Kratos.

Pretty sure! We have documentation on importing users and already support several hashing algorithms. Support for more algorithms will follow soon!

Can you share the links if possible?

https://www.ory.sh/docs/guides/manage-identities/import-iden...

I also heard that there’s a blog post for migration coming, but it has to be translated from Japanese first. If you sign up to the newsletter you should receive a notice when it’s released :)

Is there an UI for the identity management like defining roles and assigning identities to roles?

I see the API part. But is there an UI part, besides the self-service account management?

Because that general management interface is the missing piece in many of the identity services.

It's API only. The UI is for you to create.

I wonder if "hosted Ory with a nice UI" is a viable SaaS business.

way ahead of you: https://console.ory.sh/

The system is API only (headless) but we have reference implementations available. For a management UI you can use Ory Cloud :)

For permissions, that’s a different service: https://github.com/ory/keto

Thank you for your answer.

It's nice to know there is an existing interface available, however one can drop it altogether and adopt an alternative, or create their own.

This was one of the primary reasons I ended up going with Keycloak, it's "batteries included" as far as UI goes.

UI for management, impersonation, configuration, etc... with RBAC, end-user UI for account preferences, profile, login, password reset, etc... all customizable/themeable.

With the switch to quarkus, is has a much more "single binary" feel and is very easy to deploy / configure.

Hey, I've seen the project in the past and it's very interesting, and definitely an improvement over existing alternatives. That said, I have one complaint quite unrelated to tech itself: I think the liberal use of the term "identity" is very inappropriate. Of course "identity" is an extremely hard term to even define, but as far as I can see ory kratos is only assisting with email and phone verification. To talk about "identity" on that context seems very out of place to me. Maybe there's more that I've missed, and if that's the case I'm sorry. I understand words have more than one meaning, but there are big challenges to solve with regards to identity in the digital world that as far as I can see ory doesn't try to solve at all, and we end up spending time reading through the docs and trying to see if someone is making a meaningful contribution to the field for nothing. I know competitors use the term irresponsibly too, but... nevermind.

Sorry for the rant and what may sound like a very negative comment, I wrote this quickly. I think it would be great to right away stop using the term "identity" so freely and use something else, or at least clearly explain what do you understand for identity. I think it would be great for programmers to start disambiguating the concept, and I think projects like ory have a good opportunity (that you yourselves created and built, of course!) to make it a bit better.

I usually understand "Identity" in the context of authentication and authorization to mean "who is the person or process trying to access the service", what do you think is inappropriate about this use of the word? Or another way to put it, from what should it be disambiguated?

A user account, an email or a phone number do not uniquely identify a person or process, and it doesn't tell you whether it's actually a person or a process.

Edit: "account" may not fully capture everything ory might be trying to do, but it's definitely closer than "identity".

I understand what you're saying here. I'm doing some looking-into identity as the concept of a verification that a person is who they say they are, not in the context of authentication but in the "real world". I've learned to read that word "identity" very loosely. As you said - it's very had to define.

Hm. I agree with you: Identity is a user account or role. Verification is backing up the assertion of initial registration with phone, email, address, and so on.

Authentication is the verification of identity after registration.

Authorization is the verification of permission for an identity to take an action.

Is there an SSO for api/rpc just like how github cli (gh) did their auth (gh auth login)? I've been looking for simple tutorials on how to get started with a bunch of openid libraries, and still not sure how to get it working with ory. I didn't proceed spelunking github code and end up settling on session management.

Using it professionally at my current client, seems solid so far. Good work!

We use hydra. Very interested in Kratos. Thanks for the contribution. :)

Congratulations on Kratos coming out of Beta.

We evaluated Ory a few months ago. My understanding:

1. Ory Kratos provides session-based authentication and user management.

2. Ory Hydra is a self-managed server that secures access to your applications and APIs with OAuth 2.0 and OpenID Connect.

Basically we want to replace AWS Cognito (which is pretty much abandonware) to secure our API so we needed both applications. Unfortunately we had to put our efforts on hold:

1. Bugs around traits meant we had issues around password change, password recovery and email change/reverifications for our use-case

2. Lack of documentation prevented us making progress on 2FA/WebAuthn

3. Bearer token/Oauth consent flow wasn't available without a lot of work because Kratos and Hydra are not "integrated" [1]. Someone shows how they rolled their own integration [2].

I'd love for someone to advise that we were wrong or misunderstood things or that things have moved on since then!

[1] https://github.com/ory/kratos/issues/273 [2] https://blog.px.dev/open-source-auth/

> 1. Ory Kratos provides session-based authentication and user management. > > 2. Ory Hydra is a self-managed server that secures access to your applications and APIs with OAuth 2.0 and OpenID Connect.

Sounds about right.

> 1. Bugs around traits meant we had issues around password change, password recovery and email change/reverifications for our use-case

Can't comment much on these as I haven't experienced those issues, but I'm curious to hear what the issues were.

> 2. Lack of documentation prevented us making progress on 2FA/WebAuthn

Things have moved on in the last months, and the 2FA/WebAuthn implementation seems more mature and documented.

> 3. Bearer token/Oauth consent flow wasn't available without a lot of work because Kratos and Hydra are not "integrated" [1]. Someone shows how they rolled their own integration [2].

That's right, sadly there's no 'integration' available officially. There've been at least two pull requests (I made one of them) to add Hydra integration to the official demo Kratos UI, which for different reasons weren't merged. I'm not sure I'd say it's so much work (essentially, it's getting the existing Kratos session and translating those into a Hydra session, with a couple of API calls), but it's not something very well documented (or at all) and you're left to figure it out by yourself from the API documentation. I hope that integration between the two is improved, at least with an official demo showcasing the calls needed in order and with the right parameters.

We experienced issues with the settings API not updating traits. Will try again now that things have moved on.

Regarding Kratos and Hydra is this[1] your PR?

[1]https://github.com/ory/kratos-selfservice-ui-node/pull/149

The Ory suite seems like quite an amazing project! I have read through quite a bit of the documentation and I really appreciate the in depth yet understandable explanations of Auth, OIDC and OAuth 2. Unlike other providers that just want to show you how to integrate their solutions, the Ory docs feel like the people who wrote it actually want to make me understand identity management!

The only wish I have, especially as a beginner developer: please make it easier to understand how your solution (especially Kratos as a non-standard) is integrated in my project. Many of the blog posts and tutorials only show how to authenticate and use the flows Ory provides, but it took quite a while to find examples how the backend with the application logic actually fits into the picture.

Other than that, I really like where this project is going. I'll definitely check out the cloud offer. Excited to see what this project will become!

For anyone also looking for examples to learn from, here is what I found

As someone who knows very little about serious identity management, does something like Ory handle the auth part (in a variety of schemes), and then your application interacts with Ory somehow to validate the auth? I guess I'm most confused about where the connection between Ory and the application server is.

I've only ever dealt with auth a monolith with sessions, so I'm pretty blind here.

Any resource anyone would recommend would also be greatly appreciated!

> I guess I'm most confused about where the connection between Ory and the application server is.

There might be none. The response from an identity provider (Ory) is signed and encrypted, is given to the user who is being authenticated and then the user brings it to the application. The process usually happens via browser redirects, but can be more manual. The response contains information about who the user is, their identifiers and properties. It is totally possible to have a scenario where the application is air-gapped.

There might be some interaction if the application wants to enrich the passed response.

I cannot suggest any books, but you could search about SAML2, OpenID Connect (oidc), identity providers and service providers.

Just to clarify, as not everyone is familiar with service based architecture: When the application server is air-gapped from the identity provider, it is meant that your frontend application will have user information embedded in the requests it makes.

For example by setting a JWT in the headers or in a cookie when it's a web application.

Even the responsibility of validating that information can be extracted from the application server by doing that in the application gateway (also known as the ingress, for example nginx) which can be configured to read the JWT (or whatever format you choose) and reject unauthenticated/tampered requests.

I know this is the discussion as old as JWTs, but the tradeoff here is how do deauthenticate the user. If you delete/disable the user, or change their role, there's still a stateful JWT out there claiming they have certain grants.

You either need to accept a certain TTL on the JWT, or be able to revalidate the JWT on every request with some authoritative service to ensure the grants are good (which sort of invalidates the value of the grants encoded in the JWT itself).

That'd depend on the implementation details. Within the Ory ecosystem, you have Kratos (identity management), Hydra (OAuth2 & OIDC server, dealing mostly with token issuance, not so much with identities, which you have to provide externally) and Oathkeeper (API gateway).

For browser use cases, the recommended approach with Kratos is to use cookies (which means that Kratos need to follow the same site rules for the site it's set up for). Since Kratos is separate from the system you're trying to provide authentication for, you need some kind of token issuance, but you can make it as short-lived as you'd like. Within the ecosystem, you'd use Oathkeeper to transparently convert a Kratos cookie to an ID token, but this token can be generated with an arbitrarily short lifespan, and so you can revoke sessions with immediate or almost immediate effect.

Where things get a bit more complicated are if you exchanged that 'local' Kratos token for a different sort of token, like an OAuth2 bearer token (which may give access to external systems). In this case, ending the Kratos session doesn't immediately revoke those other tokens. You need to either accept that tokens might outlive the actual session they originated from (sometimes you might even _want_ this, for instance in an asynchronous service), or else keep track of these other tokens and revoke them individually.

If you're using Hydra for these other tokens, you can either use JWT or 'opaque' tokens. With JWT, you have the issue you mention that the token itself has some state that might become stale, but if you're using 'opaque' tokens, you don't get any claims from the token itself and you're supposed to get these from a separate introspection endpoint. You can make these introspection requests as often as you'd want, like for Kratos cookies above. Hence, if you revoke the session in Hydra (or whichever other OAuth2 server you're using) and you're validating tokens, you can revoke sessions almost immediately, with some overhead that comes with splitting a system into separate ones.

The main idea is that instead of a session cookie you are usually exchanging signed information in this scheme. Your app server or an intermediate proxy validates that the signing was authentic, and then receives some information (Often called “claims”) — such as “This account is an admin role user”, or “This account has user id 1234”.

With those pieces of information, you can do all your application lookups securely. With a bit of middleware to handle the incoming signed data (Often JWT), it probably looks about the same as your session-based authentication. The only difference is that you’ve split out and centralized your authentication (And possibly authorization via claims)!

I love the way Ory is set up and documented to be understandable and deployable as components. I played with Kratos a couple weeks ago and made a single vm deployment using sqlite on fly.io. The configuration documentation for Kratos was a bit dense, there's so much functionality in there already despite it being just out of beta so I pushed my config to github so you can get going on fly.io with it immediately:

https://github.com/tinco/kratos-service

(you can paypal me later tptacek ;))

Ory suite looks amazing. I think the biggest things I'm missing are token authentication and with that, services tokens. I saw a thread saying it'll be implemented at some point and I'm looking forward!

Thank you! :) We have an RFC for adding this type of short lived tokens to Ory Kratos. If you want to go deeper in the security space, there is also Ory Hydra which supports things like Service Accounts using OAuth2 Client Credentials (with PKI!) as well as OAuth2 Token Exchange :)

If you're looking to understand the solution that this and other tools in the suite are meant to address, check the Concepts/Overview, especially the "Solving a specific problem domain" section.

https://www.ory.sh/docs/kratos/concepts/

I know stating this silly, but it really bugs me seeing the link below at GitHub repo page.

https://www.ory.sh/kratos/?utm_source=github&utm_medium=bann...

you don't think they should be allowed to know the source of link clicks to their website

<3 I've been following Ory for a while, super interesting projects and amazing docs.

Are there any plans for SAML support anytime soon?

Yes! OVH (the cloud provider) is working on a large PR: https://github.com/ory/kratos/pull/2148

That's a "burning" PR!

This is super exciting. But slightly off-topic question: has innovation in identity management plateaued? This is coming from someone who works in a fairly large identity management team. Functionally I can’t figure out what’s the next big thing in our domain. Even passwordless stuff feels like an evolution. Is there any academic work being done in this space?

I'm passing familiar with this area, but not as familiar as I should be...

How does this compare to something like this - https://github.com/panva/node-oidc-provider

Are they addressing the same need? Is Ory looking to get certified in these area? (Is it already?)

Are there plans for handling multi-tenancy? Sort of like with Keycloak's realms.

It probably depends how many tenants you are looking at. If you have <100 or so you can deploy a kratos instance for each. With many more there is the managed Ory Cloud solution or you can build something bespoke with Ory Hydra (OAuth2 server).

Does ORY actually have 2FA yet? I remember the last time I checked it out it was pretty off putting that they advertised 2FA in the marketing material and Readme but it wasn’t actually there.

Yes! WebAuthn, TOTP, Recovery Codes, MFA Policies - it’s all there :)

https://www.ory.sh/docs/guides/mfa/overview

I think "Identity Provider" is more correct, no? "IdentityServer" is the name of a specific IdP implemented in .NET (formerly OSS as https://identityserver4.readthedocs.io/en/latest, and now as a more commercial form as Duende IdentityServer: https://duendesoftware.com/products/identityserver)

Does this work with ALTS for gRPC?

Quick question: how does this differ from keycloak? Are they competing products or do they work fundamentally differently?

One difference is that Keycloak has some UI which you can even customise for your installation. Fundamentally I guess they're similar, Keycloak is more mature but more Java.

Keycloak is more feature packed than the Ory stack. Ory is thinner than Keycloak.

Keycloak is heavy to learn but once you know it, everything is easy. It’s amazingly configurable. It has everything: saml, openid, federation, roles, groups, mappers, extensibility, authorisation services, configurable flows, …

What I like about Ory: thin components. Starts really fast, go binaries with zero dependencies.

What I didn’t like: extension points are inflexible and everything is a http call. Integration is a pita. Say you have hydra and kratos. You want kratos login but then use hydra tokens to fetch data from keto. Good luck writing the glue code.

Kratos has two things Keycloak could borrow: json identities with schemas and external ui pluggability. If Keycloak had those two, I’d never look back.

Reply on news.ycombinator.com