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.

I'd like to find anyone using Keycloak and see what they like most about it, and what we could offer in FusionAuth to make it compelling to consider switching - if IBM buying Red Hat wasn't enough of a reason. :-)

The core is not open source, written in Java.

I'd say it is always good to have options. If sessions work, that is a safe option and easy to manage state.

If at scale this option doesn't work - or at least not as well as you'd like, additional strategies are good to know.

If you plan for Pokemon Go, or Fornite scale, decoupling may be beneficial. Admittedly this is a small percentage of all of the use cases.

Adding a transaction around the webhook could help with this. At least you'd know for sure everyone has agreed upon the state of the user.

But agreed, webooks in general are not excellent for critical events in general unless there are additional ways and of confirming receipt and confirmation.

Many prevailing strategies simply persist the JWT, this works, but is more difficult to scale and sort breaks the portability idea in my opinion.

Once you persist it - you might as well be using a session. I suppose it depends on your scale - maybe with just a couple of thousand users it would work ok to store every JWT issued for their lifespan.

Seems like all GPDR did was force you to accept a cookie when you use a website - instead of actually making websites be less sucky.