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.
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 :)
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.
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.
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.
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"
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 :)
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. 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.
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 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.
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".
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.
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.
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.
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 :)
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!
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 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.
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:
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.
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?
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.
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.
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.
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!