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.

He he... enjoy. Hopefully this doesn't trigger any nightmares. https://twitter.com/bpontarelli/status/1099067076138827776?s...

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

To add to this... not trying to hide anything on purpose. :-) https://github.com/robotdan https://www.linkedin.com/in/robotdan/

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!

> + 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.

https://www.servethehome.com/red-hat-goes-full-ibm-and-says-... http://techrights.org/2020/08/02/red-hat-layoffs/

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.

FusionAuth has some k8s, helm, docker and openshift examples as well. https://github.com/FusionAuth/fusionauth-containers

FusionAuth is not open source, so if that is a hard requirement, you'll have to skip it.

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.

The last time I had to type in my Netflix password into my Roku using a d-pad I nearly chucked the remote at my TV.

Not sure why everyone doesn't use this type of device authentication.

This may be of use, this is the Authorization Code Grant, but many others are documented as well.

https://fusionauth.io/articles/logins/webapp/oauth-authoriza...

https://fusionauth.io/articles/logins/types-of-logins-authen...

+1 for FusionAuth. FusionAuth has some example k8s and helm configurations available as well.

Full disclosure I work for FusionAuth. We support all of these configurations.

Nice writeup. Brew is fantastic on macOS, do you have something similar on Windows?

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.

Like Got Milk? I see what you did there. :-)

Why? I have yet to find concrete reasons how this makes a hash more vulnerable.

Lots of people like to dismiss it, but without any reason. Seems weak.

Do you know of anyone that has used this strategy in production?

How much less suck are we talking about? Kind of sucks in most languages.