It's a good idea. The article conflates authentication with authorization. Your application can authorize many different ways, most do. You can use your session for authorization - your application can decide what a person can and can't do. But facts about the user's identity never change, like their uniquely generated ID in your database, and that's what gets stored in Keycloak's `sub` field, so it's fine to use that for trading a token for a session cookie. Their password does change but that's Keycloak's job, is to turn passwords into authentication tokens.

The JWT always stores facts about the principal (aka who or what is doing something), and those don't really make sense to revoke or whatever anyway. Stuff that will never change over time. JWTs can optionally store something like a `role` or similar fact that may change over time, specific to your application. Those facts can be used to decide what you can do in your application, that's authorization. We could talk about when and how that should be done, but it would be too nuanced for these evergreen JWT blogposts.

Taking complete systems off the shelf and using them smells a lot like money. If/when your app requires enterprise integration, you'll be fanatically happy that you chose Keycloak over having to implement okta... then ldap... then.. Saml... then.. Kerberos... then ldap again with custom mappers..