
A guide to Oauth2 - milap
https://milapneupane.com.np/2019/09/02/a-complete-guide-to-oauth2-protocol/
======
pierreyoda
I'm currently in the middle of implementing an OAuth 2.0 authorization server
following the RFC draft of the best current practice [1].

It's been a huge pain navigating all the interlinked (and sometimes
contradicting) RFCs around, especially with a distinct lack of resources for
actually _implementing_ an authorization server. RFC6749 does not suffice on
its own since it says nothing about authentication or tokens payload (not that
it should). I did discover the whole RFC universe which are mostly fascinating
and very well written.

Most google searches end up to Auth0 (nice SEO!), which I'm sure is a fine
product, but usually only gives a very high-level overview of the
corresponding spec and ends up like "see how this is all complicated? there's
a SAAS for that...".

I'm seriously considering implementing a fully spec-compliant OAuth 2.0 +
OpenID Connect Core 1.0 reference server implementation in Typescript, with
full documentation quoted straight from the RFCs. The HOW is actually pretty
straight-forward once you've figured out the WHAT and WHY.

[1] [https://tools.ietf.org/html/draft-ietf-oauth-security-
topics](https://tools.ietf.org/html/draft-ietf-oauth-security-topics)

~~~
sjroot
I’m actually working on the same thing but in Rust. If you ever want to
compare notes sometime, give me a shout out.

I’m actually kind of glad the documentation found via google searches (save
one collection of Medium articles) has been disappointing. It has motivated me
to look directly at the specification which I’ve found to be the most valuable
resource thus far.

~~~
pierreyoda
Oh yeah definitely!

Rust would be awesome but I think I'd want it to be as accessible as possible.
Tagged unions and proper error handling would make it much saner though that's
for sure.

~~~
sjroot
I was initially going to do it in TypeScript, as the clients that will be
interacting with it are TypeScript. Can’t really go wrong either way, but
yeah, I’ve enjoyed exploiting Rust’s type system!

~~~
microcolonel
Be careful to do the hard stuff in workers, otherwise your throughput will be
limited by one core.

Sorry if that's so basic of a consideration that it's insulting, but I've seen
it done before.

------
blr246
It's worth mentioning that it's a bad idea to invalidate refresh_token grants
ever during the lifetime of an authorization. I've seen APIs do this
immediately upon sending the response to the token endpoint, which makes the
system unusable due to the frequency of network transmission errors that would
result in having to contact the resource owner to grant access again. Even an
expiry after days and years is only likely to result in more support requests
to the API maintainer without increasing security enough to justify it.

The reason this bad practice is common is that it is allowed by the spec in
[https://tools.ietf.org/html/rfc6749#section-6](https://tools.ietf.org/html/rfc6749#section-6)
as an optional action to take on refresh grants. Please, do not do this.

~~~
darkerside
I've always believed it should be the responsibility of the consumer (perhaps
with the aid of client libraries) to properly handle the refresh lifecycle.
I'm not a fan of password rotation, generally speaking, but it's because
humans are terrible at remembering and creating complex passwords. Software
processes don't have the same problem.

------
dvh
> You want to add all your contacts in Gmail who are in skype

Never once in my lifetime I wanted to do that. For any two services.

~~~
atoav
Above that I think this is rude to my contacts: _You can’t just go and upload
random people’s data on plattforms of your choice_.

I _get_ it – people feel like it is _their_ contacts because they collected
them, but they are not. This should be illegal.

~~~
ailideex
So you don't store numbers of any of your contacts? You must have some insane
memory ... but then again ... maybe memorizing random people's data should
also be illegal... I mean did the people who told you those details give you
permission to memorize it? I think not. And when you enter those memorized
details into your browser or phone ... who gave you permission to do that?!
Blatant GDPR violations.

~~~
atoav
If only there was some way to store contacts without uploading them..

Has it really come to this? If you open your phone now you usually have two
offline options: to store contacts on the SIM card and to store them on the
phone.

If you want backups and comfort without betraying your contacts you run your
own nextcloud instance and store them automatically on there.

------
kerkeslager
OAuth2 isn't a standard protocol. A real standard protocol is one where you
can build a library around it and then use that to communicate with anyone
else who conforms to the standard. OAuth2 is more of a description of the
various homegrown authentication methods different websites have tried to
create. None of those websites want to reimplement their auth to conform to
the standards, so they just add their auth to the standard. This is standards
conforming to practice, not practice conforming to standards.

Can you imagine if the HTTPS standard had to have 100 different variations to
connect to 100 different sites on the net, with no way to detect which one was
in use, so that you had to have the variations hardcoded for every site you
visit? Because that's where we are with OAuth.

Worse, some of the practices which are now RFCs are complete garbage. The
grant type Resource Owner Password Credentials[1], for example, requires that
the third party server ask the user for their username and password. _This
defeats the entire purpose of OAuth._ Don't give me some crap about this being
useful for first-party servers: there are way simpler and more secure ways to
authenticate first party servers. OAuth is for authenticating users with
_third-party servers_ , and you should absolutely, unequivocally _not_ be
letting third party servers ask the user for their username and password. This
normalizes putting your passwords for one site into another site for
nontechnical, which is outright irresponsible and unethical.

Yet in the handful of times I've authenticated with OAuth as a third party,
more than one of the first-party sites I was authenticating with used this
method, putting the onus on _me_ to correctly handle _their_ usernames and
passwords. The reasons are obvious: 1. Doing it the insecure way is easier
because it allows sites to avoid implementing an SSO portal to handle their
own passwords and grant initial access (which, incidentally, isn't included in
the standard protocol at all AFAIK, despite being necessary to make it work)
and 2. The IETF somehow thought it was a good idea to give this awful security
practice an air of validity with an RFC.

The OAuth2 protocol standard is a tire fire which is unsalvageable at this
point. We need a new standard that is actually a fully-specified standard,
with a single, clear path from start to finish, including the initial use of
passwords to obtain tokens, which serves the single purpose of allowing third
party services to authenticate in a _secure_ way.

[1]
[https://tools.ietf.org/html/rfc6749#section-1.3.3](https://tools.ietf.org/html/rfc6749#section-1.3.3)

~~~
webhamster
FYI, the IETF plans to deprecate the Resource Owner Password Credentials Grant
you are talking about [1].

[1] [https://tools.ietf.org/html/draft-ietf-oauth-security-
topics](https://tools.ietf.org/html/draft-ietf-oauth-security-topics)

~~~
kerkeslager
Okay, but why was this ever put into a standards track in the first place?
This isn't an obscure error, it's the kind of glaring error that shows that a
security standard is being designed by people who know next-to-nothing about
security. Recently, when I implemented authentication to a site that used
Resource Owner Password Credentials, my client's CTO reported it as a bug
because he (correctly) noticed the security flaw. If you're making this sort
of error, you have no business writing production authentication code, let
alone _standards_ for production authentication code.

And this is only the most glaring error. Another example: there's no
specification for how to generate tokens, and I've implemented OAuth for
platforms that return tokens which look suspiciously like UUIDs. Not only are
UUIDs explicitly recommended against as credentials by RFC4122[1] because
people could reverse engineer your UUID generation, but collisions have
occurred in practice[2] without any reverse engineering, meaning that a user
could authenticate as another user without even hacking.

And to clear, I'm not a security auditor and I've never done a security audit
of any OAuth implementations except my own. These are problems I discovered by
treating other people's OAuth implementations as black boxes, all of them
compliant to the so-called "standard". Security is hard, and with so little
specified, I imagine the majority of OAuth implementations in the wild are
actually not secure.

[1]
[https://tools.ietf.org/html/rfc4122#page-16](https://tools.ietf.org/html/rfc4122#page-16)

[2]
[https://en.wikipedia.org/wiki/Universally_unique_identifier#...](https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions)

------
thecopy
This is far from a complete guide to the OAuth 2 protocol. I would recommend
anyone wanting to communicate with, or implement a OAuth 2 server, to use the
official RFC's as a reference.

------
ken
What I’ve never been able to get a clear answer to is: how do I troubleshoot
an Oauth workflow? I set up all the Oauth stuff on my end just as the
documentation says, and the Google server (for example) returns an error. Now
what? They don’t let me see their logs. The error message isn’t descriptive
enough to know what to change. Google isn’t running an open source server
where I can just spin up an instance myself to try it. The documentation seems
to be out of date, or otherwise doesn’t match what I’m seeing.

This is everything I hate about using remote APIs, squared. I’ve never been
able to make even the simplest example work.

~~~
perl4ever
I was trying to use Oauth to log in to an internal SharePoint site with VBA,
and I _did_ get some example code to work after a lot of messing around, but
then it mysteriously stopped working a week later,* so I gave up and went back
to scripting a browser.

*possibly because some system administrator noticed abnormal traffic and blocked it

------
diafygi
Are there similar posts like this for UI best practices for implementing OAuth
2.0 as an authorization server? I've been looking for guides on how best to
display the scopes and client details to the user, but I've basically had to
rely on other authorization servers themselves for inspiration (Google,
Github, etc.).

Has anyone written a blog post about OAuth authorization server UI design?

------
afarrell
If you like diagrams, I've found that @darutk on Medium has some really good
explanations of Oauth2 and OpenID. Example:
[https://medium.com/@darutk/diagrams-of-all-the-openid-
connec...](https://medium.com/@darutk/diagrams-of-all-the-openid-connect-
flows-6968e3990660)

~~~
softwarelimits
Such great content now hostage to that website, what a pity.

Also look at their nice django-oauth-server:
[https://github.com/authlete/django-oauth-
server](https://github.com/authlete/django-oauth-server)

------
apatheticonion
My experience using OpenID + OAuth2 was fantastic. I'd recommend delegating
the responsibility of authentication to a third party like Cognito, Auth0 or
Okta.

They can be pricey at scale, but as long as you follow the protocol without
cramming more functionality into authentication than belongs there, you can
swap them out for a self hosted solution.

------
perttir
Im not sure there ever will be a complete complete oauth2 considering everyone
who implement it have their own flavor of it.

~~~
checker
Yeah this is far from complete. It doesn't even mention OAuth scopes or
standard flows. A more appropriate title would be "A Beginner's intro to
OAuth2". This is way better:

[https://medium.com/@darutk/diagrams-and-movies-of-all-the-
oa...](https://medium.com/@darutk/diagrams-and-movies-of-all-the-
oauth-2-0-flows-194f3c3ade85)

