[modernpacifist]

To answer as best as possible given the vagueness:

Cookies: Highly compatible with most if not all browsers (and even headless tools). Lends themselves to having an expiry date and generally best when used with time sort of short-lived expiring session.

JWT: Everyone tends to use these in a stateless manner which means once issued, somewhat impossible to revoke without invalidating all JWTs or having a blacklist (and we're back at stateful). Plus some implementations had issues with downgrade attacks I think it was...

OAuth 1: Fine assuming you could keep clocks in sync and guarantee the secure storage of the keys/secrets. Good in that it didn't rely on HTTPS but if the secrets ever got compromised then the attacker would have free reign of that account until detected.

OAuth 2: Basically a complicated way to get short lived session tokens, potentially from a 3rd party API/auth source. Relies entirely on HTTPS to keep data secure in-transit and less of an issue if the session token gets compromised since its ideally short lived (because most want it to be stateless - those who keep a valid list of tokens sometimes skip the token expiry).

[dwaite]

Re: OAuth 2, once you carve out everything but the code flow and token refreshes it becomes harder to imagine simplifications that don't remove important functionality.

The flow becomes "redirect the user to have them authenticate, getting back a code. Make an API call to trade that code in for access. Once access expires, try to refresh it. If refreshing fails, send the user back to re-authenticate.".

The challenge people tend to hit is mistakenly trying to implement broad + reusable code at the start. OAuth 2 is described as a framework (e.g. optional parts and extensions leading to most likely non-interoperable implementations). Without a profile like OpenID Connect Basic Client, this includes a lot of extra work. Once you stop striving to implement generic interoperability in your client (or shoot for a limited profile like OpenID Connect Basic Client), the whole client implementation can fit in < 1 page of code.

[rkangel]

Ok, good - thanks for confirming that. I haven't had to implement Oauth2 quite yet but that was my impression from reading what needed to be done, but that impression was at odds with a lot of internet rants.

[tetraodonpuffer]

> JWT: Everyone tends to use these in a stateless manner which means once issued, somewhat impossible to revoke

you can still do an oauth-like session + refresh token even with your own JWT implementation, just have a "refresh my session" endpoint that you go to with your refresh token (which is blacklistable), and have all the other calls be authenticated with the short-expiry stateless session token instead.

[jehlakj]

Which is probably the most robust and scalable of them all. I was wondering some some services took 30m to an hour to revoke access, and this is the reason why. Only downside is you have to use JavaScript on the browser, which isn’t much of a problem really.

[zaarn]

You don't specifically need JS here.

Any endpoint could automatically update the user session token when it detects it's about to run out and update the cookie that it is stored in.

[jehlakj]

Oh right! I totally forgot that you could use cookies for JWT. It's been a while, but I think the reason why I didn't think of it was because, if you're using cookies to transport jwt, couldn't you just use signed cookies with a set expiration date?

[kevlened]

Before going all the way on cookies, make sure to consider whether you're creating a mobile app, as mobile apps usually don't handle cookies for you automatically. In my experience, OAuth is a bit easier in mobile. If you support cookies for browsers and OAuth for mobile, your API will have to support both authentication methods.

[jakelazaroff]

If OP isn't allowing third parties to authenticate through their API there's really no reason to use OAuth.

[kevlened]

To echo a sibling comment [0], if you don't use OAuth2 (or the OpenID Connect profile), you'll end up reimplementing similar functionality. There are libraries for OAuth2/OpenID Connect, while a custom authentication strategy requires more effort.

[0] https://news.ycombinator.com/item?id=16519660

[lilbobbytables]

Why not tokens? They're easy and work well with an Authorization header on mobile.

[coldacid]

I'd argue that they can also be implemented in a much more lightweight fashion than having to go through a whole OAuth flow just for a mobile app that hits an API that you control completely.

[tytytytytytytyt]

Then you have to deal with password resets and account creation, which if you know how those work, don't really sound all that lightweight compared to OAuth 2.

[kevlened]

I'm not sure what you mean. The OAuth2 spec defines access tokens and also specifies that they should go in an Authorization header.

[dwaite]

To be clear, OAuth 1 security over HTTP was pretty terrible all around. The cryptographically signed requests only supported a small subset of possibly HTTP requests (i.e. it didn't protect a JSON POST), and there was no protection whatsoever on server responses.

It doesn't do nearly as much good as one would hope knowing that a request came from a particular client if that request was possibly based on erroneous data, manipulated by a malicious third party.

[mezzode]

Having a blacklist is probably still preferable to storing every session though in that there should be less data stored, if only marginally

[amend]

I just updated my question, as it was vague. I’d appreciate your input!