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.
Keycloak: Open-Source Identity and Access Management
241–243 of 243 posts
Re: Keycloak: Open-Source Identity and Access Management
#242Earlier 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?
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
#243Earlier 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…
Seems like your other Java services were not an issue though?