when it comes to this kind of things there's really no way around it: you're supposed to read the RFCs:

- https://www.rfc-editor.org/rfc/rfc6749.html: The OAuth 2.0 Authorization Framework

- https://www.rfc-editor.org/rfc/rfc6750.html: The OAuth 2.0 Authorization Framework: Bearer Token Usage

As someone who is hired to sling out features as rapidly as possible, that’s not going to happen.

I mean, you might say “but you should” or “it would actually help” or “in an ideal world…” but it is still, realistically, not going to happen.

Well hopefully someone has taken the time to, or there will be nasty surprises

I certainly don't want people building security sensitive parts of an app to be slinging the features out.

> As someone who is hired to sling out features as rapidly as possible, that’s not going to happen.

you do you, i guess.

but that's where the source of truth about how oauth 2.0 works is.

the "why" you're looking for it's in there.

...you can't really have it both ways, though. Either you have time to read the detailed docs, in which case there they are in grandparent's post; or you do not, in which case you're going to be putting up with simplified black box abstractions and whatever problems occur when the use case the designer of those had in mind while hiding the complexity from you does not match your own.

That doesn't explain what the library is trying to do and how it implements it though.

if the library is implementing oauth 2.0, that explains what the library is trying to do.

how it's implemented... well that's an implementation detail, that most often one couldn't understand without the domain knowledge (unless it's something "trivial" like an off-by-one in some string comparison or something like that).

Yes, that "domain knowledge" is kinda important when you're trying to debug a blob of code that results in random permission errors after OAuth request.

The "implementation details" are what we're tasked with implementing ;)

The difference is that the RFC covers everything, whereas OAuth providers choose a subset of what they actually want to support.

Search engine > Encyclopedia

Asp.Net authentication is 10 times worse in this regard.

Not sure if they still do this, but when I first started learning, front and center of the documentation was telling you how to do it in a mobile app, then JS SPA app. The use case of a backend API+JS/mobile frontend was buried. And it was all stupidly named. It wasn't blatant like 1) MOBILE APP FRONTEND 2) JS APP FRONTEND 3) API BACKEND + FRONTEND.

So for me, mobile wasn't relevant, SPA wasn't relevant, and my use case, the third one was hard to find.