Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keycloak: Open-Source Identity and Access Management

keycloak.org

Post reply on HN
Print view View original

141–150 of 243 posts

Re: Keycloak: Open-Source Identity and Access Management

#141

Post by zeepzeep »

chrisoverzero wrote: post #41
schipplock wrote: post #20

In Keycloak nothing made sense to me until I got myself familiar with OAuth 2.0 and OpenID Connect. Keycloaks documentation seems vast, but isn't. There is also no way to search inside their documentation. It's a pity. A better documentation is contained in the administration web ui itself. There are so many "hints" and tooltips for almost every option there is. It really helped me a lot. Keycloak is good software. I…

> Beware: they aren't using Docker Hub anymore. Newer versions are on Quay only Oh, right, Quaycloak.

Quaaludes... what?

Re: Keycloak: Open-Source Identity and Access Management

#145

Post by freedomben »

password4321 wrote: post #87
schipplock wrote: post #20

In Keycloak nothing made sense to me until I got myself familiar with OAuth 2.0 and OpenID Connect. Keycloaks documentation seems vast, but isn't. There is also no way to search inside their documentation. It's a pity. A better documentation is contained in the administration web ui itself. There are so many "hints" and tooltips for almost every option there is. It really helped me a lot. Keycloak is good software. I…

> Keycloaks documentation seems vast, but isn't. There is also no way to search inside their documentation. This is one area where incentives don't align correctly for open source projects that offer commercial support.

Disclaimer: Former Red Hatter but worked on OpenShift, not Keycloak

Working as a person providing commercial support for open source projects, I promise it doesn't actually work that way. Incentives are entirely for creating good documentation. Having crappy docs only hurts project adoption for paying and non-paying customers, increases the support burden, and wastes the time of your employees (who are the primary consumers of that documentation).

Usually documentation isn't great because writing (and maintaining!) good documentation is really hard. It's a continual effort and it takes engineer time away from bug fixes and feature dev, two things for which there is never ending demand for.

Edit: Pro-Tip: With Red Hat projects (like Keycloak, OKD, etc) it's always worth looking at the RH product docs as well as "open source" docs. For example if you use OKD, check OpenShift docs as well as OKD docs. You do (unfortunately and I wish they'd remove this) usually have to log in to a Red Hat account but you don't have to pay. You can create a free account and use that.

Re: Keycloak: Open-Source Identity and Access Management

#146

Post by freedomben »

mooreds wrote: post #70
oauea wrote: post #67

Earlier quoted context omitted.

> Disclosure: I work for FusionAuth. Don't worry, that was obvious.

Ha ha, fair enough. I've found it better to err on the side of transparency.

I would offer two suggestions that might improve reception:

1. Put that disclaimer at the top

2. Shrink it to no more than a couple sentences and link to a blog post or something for the detailed comparison. It looks pre-canned and kind of spammy the way it is now

Re: Keycloak: Open-Source Identity and Access Management

#147

Post by spion »

zmxz wrote: post #124
littlecranky67 wrote: post #110

Earlier quoted context omitted.

The problem with the authorization code flow is, it was not build with SPAs in mind. I.e. you always need a server-side component that obtains those tokens. So a 100% client/FE solution based on NextJS/React/angular/vue etc. can not simply be deployed to a CDN and then use Auth0/AWS Cognito/Azure AD whatever without running and hosting your own server-side component.

SPA is HTML/JS served by the server . We don't need client-only solutions. We need devs to understand how HTTP and browsers work. It means that we simply keep using what actually works, i.e. serverside component that obtains authorization and we use simple mechanisms to ensure token stays at the server and FE speaks to the server which in turn speaks to the target app. Proxying is not that difficult of a problem and…

You've misidentified the problem.

We need CDN solutions for front-ends because that's the best way to deliver great, scalable performance for complex SPAs.

We also need a purely client-side flow for mobile (native) apps.

Additionally, the authorization code flow (with PKCE) in Keycloak still supports pure client side authorization. Its more complex than the implicit flow, but it doesn't really matter as any library (including keycloak-js) will take care to ensure its done correctly.

Re: Keycloak: Open-Source Identity and Access Management

#148

Post by nickserv »

miovoid wrote: post #142

It’s Java based :—(

I'm not a big fan of Java personally, as in I would not start a side project with it.

But in this case it's actually a great choice. Static typing, stable, mature, good performance, known by tons of engineers all over the world... And heavily used in the enterprise market which has a very real need for SSO.

Re: Keycloak: Open-Source Identity and Access Management

#150

Post by topspin »

deependra wrote: post #31

Another Opensource IAM provider is WSO2. Now they offer a cloud solution too. https://wso2.com/asgardeo/

I've used both the opensource WSO2 and Keycloak. That latter is better designed and suffers fewer glitches, which is important when dealing with the complexities of oidc/oauth2. It's not that WSO2 doesn't do what it says on the tin; it works. Keycloak just works so well it's almost fun.

One feature Keycloak lacks compared to WSO2 is SCIM (System for Cross-domain Identity Management). That actually matters to me. There is a third party Keycloak extension[1] that implements SCIM, but I can't speak to it.

[1] https://github.com/Captain-P-Goldfish/scim-for-keycloak

Post reply on HN