If this was all the way transparent about Keycloak they’d make it clear that Keycloak is the upstream for Red Hat SSO, which has support options from Red Hat/IBM and so on. It’s a little bit different model from theirs, but no less valid.
Because it's a 3rd party, it cannot be non-compliant?
Seems like it's 1 extra click to disallow compared to allow, so yeah, non-compliant. Should be exactly as easy to say yes as saying no. In this case it's not.
It's not overblown criticism. They advertise their product as GDPR-compliant, and yet their website uses dark patterns to trick people into allowing tracking, and is not GDPR-compliant.
Do I trust them to be as diligent in their product?
And yeah, what gives GDPR bad rep is exactly these kinds of dark patterns and other forms of malicious compliance by non-caring companies.
It's their choice to chose that banner, and their choice to configure it this way. Most third-party banners are non-compliant, including this one. Which they should know, given that they advertise GDPR compliance for their main product.
The banner should have a Reject All option, preferably as default action.
I understood its something to do with auth but even the comparison pages didn't clarify in meaningful ways how it's different. I don't see how this could help me get more users - that's my job not yours.
I was also confused what a network has to do with auth. Is this some kind of distributed auth product? Who knows.
Also, I don't think anyone looking at a saas auth product would consider rolling their own. Presumably they're on your site because they aren't interested in that.
So I just didn't know what your value proposition is.
I think their Github "About" text is quite clear imho. An open source identity service that can be an alternative to similar commercial ones like Okta, Auth0.
Founder / project creator here. Ory Kratos has been in development since 2018 and is approaching version 1.0! If you have any questions about the project, tech, flows, or Ory as a whole I’m here to help :)
Is this an alternative to Keycloak? One thing Keycloak supports is the ability to create multiple realms in order to use one instance for different groups of users and applications. Does Kratos support something like that?
Isn't that aspect of Keycloak a carryover from the days when one VM held one instance of an application? These days containers are cheap and you can just spin up each "realm" in another container.
Just because you can architecturally do that today, doesn't mean that you have to and that everyone does.
I do run Keycloak in a container but I'm pretty sure spinning up a new instance for every realm would be more resource intensive than using multiple realms in the same instance.
It's just a question of use case at the end of the day. In my use case I only need this for small internal tools so it's easier to just spin up one instance for me.
Are there any plans to support multi-tenancy? I understand that the current recommendation is to run multiple separate deployments, but will it be supported for a single deployment?
A while ago my team needed exactly this kind of auth solution, so the eng team reached out to Ory to clarify some technical questions that weren't covered by the docs. We were super enthusiastic about Ory. It looked solid, was open-source, and ticked all the right boxes.
We got an immediate response by a very motivated sales person who insisted to be connected with management and refused to put us in touch with anybody technical. It was a pretty off-putting experience, because it basically presumed that our eng team wasn't the decision maker (it was). I know a lot of companies throw their sales people at you, wanting to get in touch with somebody higher in the org chart, but it's still a pretty insulting experience for a tech-driven organization.
Needless to say we went with something else (not Auth0 either) and have been very happy.
Hey, Founder here. Sorry to hear that. The sales process should be a net benefit for anyone involved. I’m really keen on fixing this (and had my fair share of bad sales calls too). Would you mind sending me a quick email to aeneas@ory.sh - I just want to figure out what needs to change for the org to become better. Appreciate it! I won’t sell you anything, promised ;)
Can't share that experience.
We are in the process of migrating from Azure B2C to ORY Network and had also some initial doubts if their products are a good fit for our enterprise company.
Our company is three hours away from their office in munich, but they were willing to send us an experienced engineer to answer all of our questions. This was very much appreciated and helped us a lot. They also offer the possibility to purchase dedicated slack channel support.
> ...basically presumed that our eng team wasn't the decision maker (it was).
I work at an auth company as well, Stytch, and this is something that we treat as obvious but we've seen a lot of reports like yours. Auth is such critical infrastructure, it is always going to come down to the technical team in the end.
I want to love ory but honestly I have no idea how to integrate it like I can with supertokens. Literally looking to move from supertokens and have spent 4 hours trying to grok how to make the change. The docs are OK but how the products interconnect is super opaque.
I can’t believe that people use closed source auth solutions. As a security engineer, I am so thankful that Ory exists. If you can’t run your auth stack locally, your engineers will find work arounds for the inevitable pain/frustration due to some undocumented behavior that they can’t self service a root cause understanding.
Why are people still using Ory Kratos? It's still incredibly confusing documentation. Large fan of projects like: https://supertokens.com/ that focus on making authentication workflow implementation really easy.
50 comments
[ 11.5 ms ] story [ 1525 ms ] threadhttps://www.ory.sh/comparisons/
https://www.ory.sh/comparisons/ory-vs-keycloak/
the chart may be hidden "below the fold," so scroll down.
I gave up previously because having the user create button "above the fold" implied that an account was needed to view the comparison. SMH.
Seems like it's 1 extra click to disallow compared to allow, so yeah, non-compliant. Should be exactly as easy to say yes as saying no. In this case it's not.
Do I trust them to be as diligent in their product?
And yeah, what gives GDPR bad rep is exactly these kinds of dark patterns and other forms of malicious compliance by non-caring companies.
Not at all. My point was that they are not offering that as product.
The banner should have a Reject All option, preferably as default action.
Also relevant: https://noyb.eu/en/where-did-all-reject-buttons-come
I was confused about that for a while.
Ex:
Login & Authentication -> Kratos
Permissions & Access Control -> Keto.
You could take some cues from Grafana here.
Similarly to Ory, their product is backed by OSS.
Their frontpage’s navigation bar makes it clear which is backed by which.
I was also confused what a network has to do with auth. Is this some kind of distributed auth product? Who knows.
Also, I don't think anyone looking at a saas auth product would consider rolling their own. Presumably they're on your site because they aren't interested in that.
So I just didn't know what your value proposition is.
not sure if that is everything.
I do run Keycloak in a container but I'm pretty sure spinning up a new instance for every realm would be more resource intensive than using multiple realms in the same instance.
It's just a question of use case at the end of the day. In my use case I only need this for small internal tools so it's easier to just spin up one instance for me.
LE: I guess it's being tracked in this GitHub issue: https://github.com/ory/kratos/issues/274
We got an immediate response by a very motivated sales person who insisted to be connected with management and refused to put us in touch with anybody technical. It was a pretty off-putting experience, because it basically presumed that our eng team wasn't the decision maker (it was). I know a lot of companies throw their sales people at you, wanting to get in touch with somebody higher in the org chart, but it's still a pretty insulting experience for a tech-driven organization.
Needless to say we went with something else (not Auth0 either) and have been very happy.
I work at an auth company as well, Stytch, and this is something that we treat as obvious but we've seen a lot of reports like yours. Auth is such critical infrastructure, it is always going to come down to the technical team in the end.
It makes cost much lower and more consistent.
I would have thought the opposite given that they'd be charging per user per day as opposed to an all you can eat in a given month for a single user.