[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.