I'm currently in the middle of implementing an OAuth 2.0 authorization server following the RFC draft of the best current practice [1].<p>It's been a huge pain navigating all the interlinked (and sometimes contradicting) RFCs around, especially with a distinct lack of resources for actually <i>implementing</i> 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.<p>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...".<p>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.<p>[1] <a href="https://tools.ietf.org/html/draft-ietf-oauth-security-topics" rel="nofollow">https://tools.ietf.org/html/draft-ietf-oauth-security-topics</a>
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.<p>The reason this bad practice is common is that it is allowed by the spec in <a href="https://tools.ietf.org/html/rfc6749#section-6" rel="nofollow">https://tools.ietf.org/html/rfc6749#section-6</a> as an optional action to take on refresh grants. Please, do not do this.
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.<p>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.<p>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. <i>This defeats the entire purpose of OAuth.</i> 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 <i>third-party servers</i>, and you should absolutely, unequivocally <i>not</i> 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.<p>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 <i>me</i> to correctly handle <i>their</i> 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.<p>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 <i>secure</i> way.<p>[1] <a href="https://tools.ietf.org/html/rfc6749#section-1.3.3" rel="nofollow">https://tools.ietf.org/html/rfc6749#section-1.3.3</a>
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.
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.<p>This is everything I hate about using remote APIs, squared. I’ve never been able to make even the simplest example work.
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.).<p>Has anyone written a blog post about OAuth authorization server UI design?
If you like diagrams, I've found that @darutk on Medium has some really good explanations of Oauth2 and OpenID. Example: <a href="https://medium.com/@darutk/diagrams-of-all-the-openid-connect-flows-6968e3990660" rel="nofollow">https://medium.com/@darutk/diagrams-of-all-the-openid-connec...</a>
My experience using OpenID + OAuth2 was fantastic. I'd recommend delegating the responsibility of authentication to a third party like Cognito, Auth0 or Okta.<p>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.