Live data from Hacker News

Keycloak: Open-Source Identity and Access Management

keycloak.org

241–243 of 243 posts

Re: Keycloak: Open-Source Identity and Access Management

#241
post #236

Earlier quoted context omitted.

Storing access tokens in Javascript and storing them in a native application have about equal protections - but by far most Javascript apps are left far more susceptible to third party code execution. The answer is typically to make such credentials incapable of being exfiltrated by adding proof-of-possession, such as the use of MTLS or of the upcoming DPoP mechanism. Note that preventing exfiltration doesn't prevent…

I really appreciate your effort, but somehow you just produce a lot of text without arguing against my point: OAuth 2.0 in a FE SPA is just broken, or "difficult" at best.

a) The text explains how its not broken b) Its not difficult if you use a library that ensures this is done correctly. Otherwise yes, secure auth is difficult, just like its difficult anywhere else.

Re: Keycloak: Open-Source Identity and Access Management

#242

Earlier quoted context omitted.

We're actually working on a new version of the Administration UI at the moment (I'm one of the devs) so this is useful feedback. We're looking for folks to try it out, so take a look at https://github.com/keycloak/keycloak-admin-ui/ . You can try it out on the latest Keycloak by passing the --features=admin2 flag on startup.

Will this have an impact on the auth screens and the related theming?

Theming the Administration UI in the new version is a lot harder as it relies more on JavaScript for rendering than FreeMarker templates in the old one. We're keeping the option to use the old interface around until this has been mitigated.

That said, we are now relying on PatternFly (https://www.patternfly.org), which allows quite some customization through CSS variables.

As for the authorization screens, these are out of scope for the changes we're doing here. But they will probably get pulled into their own refactor at some point.

Re: Keycloak: Open-Source Identity and Access Management

#243

Earlier quoted context omitted.

> my #1 complaint at the time was how heavyweight it was, which was a burden for development What do you mean by "heavyweight"? I ask because Java in other large open source projects (Elastic Search, Cassandra, Android) and it really depends on how its being used (by Keycloak as well) I've also come across GraalVM which can significantly reduce Java memory consumption (if that is something you are referring to)

Well just bear in mind that this was about 4 years ago (we were fairly early adopters apparently), and I understand that my comments here are probably no longer fair, and probably don't apply to KC at it is today. But since you asked, basically Keycloak was by far the single largest component of our stack, which didn't sit well with me because by any measure, our application was far more complex than Keycloak. At the…

Fair enough, thank you for the explanation!

Seems like your other Java services were not an issue though?

Post reply on HN