[dwaite]

If you have no other features ever planned around authentication or authorization, and no other planned client software, you can build what you want in directly.

OAuth provides an abstraction between the authentication, permission grant and user consent and getting a token representing authorization, and provides additional best practices for things like securing web and native app access, token revocation, token introspection, etc. You probably want to be in the business of improving your SaaS, not designing a secure access system.

That isn't to say you can't build something now with the idea that you will migrate away from that once you hit an inflection point in complexity due to new features.

[tptacek]

I don't think it's at all the case that OAuth builds baseline best practices regarding authentication into applications. OAuth makes --- in fact, essentially is --- a series of concessions to enable delegated authorization, which is a much harder problem than simple authentication or single-site authentication. When you use OAuth in simplistic scenarios, you're importing all the challenges (and, as this page, the RFC, and a zillion other sources show, vulnerabilities) that OAuth has to deal with to make delegation work... but for no reason.

I'd generally caution against using OAuth until you know you need it.