robotdan

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.

This thread makes me feel better with struggling to implement this. I'm not the only one.

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.

>> and integrated over time > I'm reading too much into this sentence fragment and it fills me with fear.

Lol!

Nailed it.

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 don't know that I'd even refer to this at outsourcing. If you can run it on premise, it is just "not building it yourself".

Yes, this is an excellent choice as long as all of yours apps live in the Ruby world.

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.

Keycloak is a good option, but if you're not a Java development it may feel a bit cumbersome to setup.

There are a bunch of good options out there - and all of them are likely better than trying to go it alone!

Dang that is quite a list. Thanks for sharing. Makes me think twice about my current solutions.