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