So, what we've learned is that OAuth2 is not a single thing, and that it is too complex.
OAuth specifies multiple authorization flows, each one including independent risk mitigation steps.
In my opinion OAuth2 is not "too complex". It's a subject matter that has intrinsic complexity, but one which isn't that high to be blunt.
Of course people who are oblivious to the subject and just glance at it from a distance might be tempted to dismiss it entirely as too complex. This is indeed a recurring problem in software development circles, where typically developers are too quick to criticize existing work because they don't understand requirements, are oblivious to the problem domain, and do not understand how the problems they don't understand are solved. But this doesn't mean the problem domain is complex or too complex.
There is a reason why this sort of walkthrough is very useful: those who are oblivious to the subject and just glance at it from a distance have a way to walk through the requirements and the happy flow in a easy-to-digest way. Hence the comments that now OAuth2 is actually not that complex, it's the RFCs that specify it that are the problem.
Unfortunately oauth cannot be compressed into a cheat sheet.
But yeah, oauth is absolutely something you forget right after using it and have to bootstrap every time you touch it.
What's so hard about a specific authentication flow?
You have a user, a client app, a resource service, and an authorization service. You have a sequence of requests that send data back and forth. The end result is a token that client apps can send to a resource service. What bit requires volumes to understand?
Take a minute to check RFC6749. All authorization flows in there require between 2 to 6 pages to fully define. Is this too much info to parse?
This means that if you're working on a legacy application that's using something like the implicit grant, to actually learn about it, you need to read superseded RFCs.
Why do you think this is a problem? So old RFCs specify grant types. That's ok, that's the whole point of specifying authentication schemes. Some are not recommended? That's perfectly fine, it just means there are better, safer ways to implement a flow. Are they still widely use? That's great, you already know where they are specified. So what's the problem?
> This means that if you're working on a legacy application that's using something like the implicit grant, to actually learn about it, you need to read superseded RFCs.
I don't understand. Where do you see a problem? You said you know where a specific flow is specified, and you want to learn it. You even have a implementation? What's the problem? Does a "superseded" tag bother you?