This is a good point. Keeping it simple is always a good engineering choice.
I think one of the reasons JWTs come up so often is that if you are going to use OAuth2/OpenID Connect - ideally the Authorization Code grant, then tokens become an important component.
And many IdPs implement the OAuth2 access token as a JWT. So it may be that your IdP ends up making this choice for you. Then you have to learn how to deal with JWTs.
Thanks for the mention. We already do see quite a few Auth0 converts. I expect to gain a lot of new customers as a result of this merger in the coming months. No complaints here.
> + Redhat seems quite invested in it, so it has corporate backing. This could also be a bad thing, depending on your view of Redhat and which direction they take the product.
Yes, true. :-) We'll see if IBM feels the same way.
I think @tremon is just getting at that auth must be considered critical, and thus you should maintain some level of skill and competency to ensure you don't get blindsided.
Perhaps the distinction is just because something isn't a "core competency" does not mean it is not critical. And just because it isn't a "core competency" doesn't mean you can afford to be ignorant on the topic.
I hope IBM/Red Hat have more sense than this, but time will tell. It may not make sense for them to maintain Keycloak with all of IBMs identity solutions.
I'd like to see some of these ideas get off the ground.
Ben mentions his email and Twitter handle in the post if anyone is interested in helping or contributing in some fashion to an open source library to implement some form of this strategy.
I think one of the reasons JWTs come up so often is that if you are going to use OAuth2/OpenID Connect - ideally the Authorization Code grant, then tokens become an important component.
And many IdPs implement the OAuth2 access token as a JWT. So it may be that your IdP ends up making this choice for you. Then you have to learn how to deal with JWTs.