Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: