What Is OAuth?

At the end of a talk about Oauth 2.0 at some indie or fediverse conference during lockdown, Aaron Parecki, who was then and still is employed at Okta, was asked if it might not be worth isolating the parts of the protocol/flow that actually requires a service (i.e. protocol-aware server in the loop) from those that don't, so that you could still get limited authentication/identity-tagging if your "provider" is your personal domain where you're just hosting static site. He immediately acted like he was addressing the dumbest person in the virtual room (it was a remote conference), telegraphing through his response that he might actually be on the verge of physical pain having to deal with such an imbecilic question.

I also interact with OAuth quite a bit at work. I also have dealt with SAML.

I'd pick OAuth over SAML any day of the week, and not just because OAuth (v2 at least) is 7 years younger.

It's also because OAuth, for all its sprawl, lets you pick and choose different pieces to focus on, and has evolved over time. The overall framework tries to meet everyone's needs, but accomplishes this via different specs/RFCs.

SAML, on the other hand, is an 800 page behemoth spec frozen in time. It tried to be everything to everyone using the tools available at the time (XML, for one). Even though the spec isn't evolving (and the WG is shut down) it's never going to go away--it's too embedded as a solution for so many existing systems.

I also don't know what could replace OAuth. I looked at GNAP but haven't seen anything else comparable to OAuth.

it is, but at the same time, that's kind of great. it handles all the things. but you don't have to use them all. for me, the point of oauth is that there's this whole complicated mess of stuff that happens in the auth layer, but the end result is a bearer token and maybe a refresh token.

you can build that mess of auth yourself, or you can swap in any of a bunch of different third-party providers to do it for you, because they all just give you the same bearer and refresh token. then you can build your app in a way that doesn't care about auth, because it all gets handled inside that oauth box. are you currently serving a request that came from a client credentials grant, or an authorization code grant? was it a pkce client? it doesn't matter outside the client.

Yeah, I mean it can be, but it doesn't have to be, depends entirely on what you need. And if you need those things, like machine-to-machine authentication, where you can't establish clients up front, you need to do something about it anyways, why not just go with something others might already know?

Delegate is just a standard word, look it up on a dictionary. If anything its internal technical definition is precisely in that sentence.

>"First half of what"

The spec, the standard, half of it deals with X, the other half of it deals with Y. Namely one half being how user grants permission to a third party, and the other half being how the third party makes requests to the main data holder.

If you need another definition: OAuth is a three way protocol between users, a service provider, and a third party. A user gives specific permissions to the third party, so that the service provider can share specific resources with the third party, who acts on the user's behalf.

I do not understand what I am doing and trust the docs, but it has never been a particularly difficult setup.

How can B be sure that C is acting on A's behalf? Can A only allow C to access certain data (or send only certain data) in order to reduce risk?

A protocol that allows for that three way negotiation is OAuth.

Like with most specs, a lot of the complexity is added in the later years, by companies that have thousands of users and complex edge cases and necessities, and they are the ones dominating the council, and their needs are the ones that push forward newer versions.

So with most specs, the best way to start learning it is by learning from the oldest specs to the newest ones, so if you start by reading or using OAuth2, you will be bombarded with a lot of extra complexities, not even the current experts started like that.

If you need to catch up, always start with the oldest specs/versions.

That said, there's a lot of details that are non-trivial, especially since in many cases you actually have to deal with OIDC[2] which builds on OAuth 2.0, and so then you're suddenly dealing with JWKs and whatnot in addition.

[1]: https://learn.microsoft.com/en-us/entra/identity-platform/v2...

[2]: https://openid.net/developers/how-connect-works/

Still have scars from building directly based off the blogposts Twitter and Facebook engineers wrote about how to integrate with this. Think it wasn’t even a standard yet.

I credit that painful experience with now feeling like OAuth is really quite simple. V2 cleaned it up a lot

"OAuth is a simple idea, but with a curse: once you understand it, you lose the ability to explain it."

If you start with OAuth from the perspective of a Service Provider/resource holder, it will all come clear.

Web security is often like that as well, most people facing stuff like CORS or HTTPS, is usually not because they are trying to solve a security issue, but it's because an upstream provider is forcing them to increase their security standards in order to be trusted with their user's data.

It's pretty neat since you can have one oauth instances for all virtual hosts, e.g.:

  server {
      [...]   
     
      location /oauth2/ {
          proxy_pass       http://127.0.0.1:8469;
          proxy_set_header Host                   $host;
          proxy_set_header X-Real-IP              $remote_addr;
          proxy_set_header X-Scheme               $scheme;
          proxy_set_header X-Auth-Request-Redirect $request_uri;
      }
  
      location / {
         auth_request /oauth2/auth;
         error_page 401 = /oauth2/sign_in;
  
         [...]
      }
  }

This page might have something, but I can’t read it myself on mobile cause it shows up broken: https://openid.net/certification/certified-openid-relying-pa...

I know it’s not just OAuth but OIDC had a pretty decent provider support and I could even self-host a Keycloak instance - it was annoying to setup but worked okay in practice, could define my own users and then just get a decent login page when needed and otherwise just got into the sites I wanted.

Personally though, it felt a bit overkill when compared to basicauth for anything not run in public or for a lot of users.

I remember how stoked I was to finally get it working. It was a massive pain, but luckily there were websites that would walk through the process procedurally, showing how everything worked, one step at a time.

Most importantly, OAuth is an authorization framework, OIDC is an authentication extension built on top.

Refresh tokens are part of authorization, not authentication.

HTTP header is Authorization: Bearer..., not Authentication.

There's no such thing as "HMAC encryption", it's a message authentication code. RSA in OAuth is also typically used for signing, not encryption. Not much "encryption" encryption going on in OAuth overall TBH.

Nonce and client IDs are not "salts", but ok that's nitpicking :)