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.
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!
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.
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.
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.
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.
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.
[+] [-] skrtskrt|3 years ago|reply
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!
[+] [-] baconfly|3 years ago|reply
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 :)
[+] [-] andrewstuart2|3 years ago|reply
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...
[+] [-] Perseids|3 years ago|reply
[1] https://news.ycombinator.com/item?id=31259826
[+] [-] yacine_|3 years ago|reply
[+] [-] legorobot|3 years ago|reply
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.
[+] [-] daigoba66|3 years ago|reply
The folks behind the company and libraries know what they're doing.
[+] [-] baconfly|3 years ago|reply
[+] [-] wharfjumper|3 years ago|reply
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/
[+] [-] slx26|3 years ago|reply
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.
[+] [-] gocsjess|3 years ago|reply
[+] [-] PinguTS|3 years ago|reply
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.
[+] [-] longrod|3 years ago|reply
[+] [-] davedx|3 years ago|reply
[+] [-] ownagefool|3 years ago|reply
[+] [-] moooo99|3 years ago|reply
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
[+] [-] jjice|3 years ago|reply
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!
[+] [-] alextheparrot|3 years ago|reply
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)!
[+] [-] breton|3 years ago|reply
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.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] tinco|3 years ago|reply
https://github.com/tinco/kratos-service
(you can paypal me later tptacek ;))
[+] [-] lapser|3 years ago|reply
[+] [-] baconfly|3 years ago|reply
[+] [-] redconfetti|3 years ago|reply
https://www.ory.sh/docs/kratos/concepts/
[+] [-] yilugurlu|3 years ago|reply
https://www.ory.sh/kratos/?utm_source=github&utm_medium=bann...
[+] [-] VWWHFSfQ|3 years ago|reply
[+] [-] DavyJone|3 years ago|reply
[+] [-] scarmig|3 years ago|reply
[+] [-] baconfly|3 years ago|reply
[+] [-] throwawayk8s|3 years ago|reply
[+] [-] Nursie|3 years ago|reply
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?)
[+] [-] atonse|3 years ago|reply
[+] [-] prisout64|3 years ago|reply
[+] [-] closeparen|3 years ago|reply
[+] [-] nottennis|3 years ago|reply
https://www.ory.sh/docs/guides/mfa/overview
[+] [-] smcl|3 years ago|reply
[+] [-] kleton|3 years ago|reply
[+] [-] revel|3 years ago|reply
[+] [-] rad_gruchalski|3 years ago|reply
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.
[+] [-] vbezhenar|3 years ago|reply