2

I am developing a private API that will be used by pre-registered clients to access information on our website. We will be storing their login credentials on our server. When looking into how to ensure the security of this API, I have noticed that OAuth seems to overwhelmingly be recommended for authenticating the users. I am trying to figure out if OAuth is appropriate for a case like mine, or if OAuth is geared more for public APIs. I understand the usefulness of OAuth if you want your users to access your site through a third party like Facebook or Google, and if you want your API to be open to the public without requiring a registration. However, the overwhelming amount of info on OAuth is related to these uses. If I want a simple, private API open only to pre-registered clients, what would be the benefits of using OAuth instead of a more traditional API key authentication? Is it worth the extra complexity if you don't need the extra login functionality it provides? Thanks very much.

  • 1
    Here's a good article talking about the drawbacks of using traditional methods to protect an API, and how OAuth can help remedy these shortcomings. I hope this explains the benefits/drawbacks. scottbrady91.com/OAuth/The-Wrong-Ways-to-Protect-an-API – Daisetsu Oct 15 '18 at 21:38
  • 1
    OAuth is a depricated protocol. OAuth2 is its successor, but supports authorization. For authentication you need OpenId-Connect (which is build on top of OAuth2). – Jacco Oct 16 '18 at 10:47
  • 1
  • 1
    OpenId-Connect is useful if you want to support, for example, single sign-on for multiple applications. If in your scenario you only have a single application, traditional authentication is easiest to implement. – Jacco Oct 17 '18 at 6:51
  • 1
    Also, if you would like to use OpenId-Connect with an off the shelf provider implementation, there is a list of certified implementation available at the OpenId-Connect workgroup site: openid.net/developers/certified – Jacco Oct 17 '18 at 6:56
2

Assuming that the API clients need to access information on their own behalf, rather than on a third-party user's behalf, then that should correspond to the "Client Credentials" authentication flow in OAuth 2.

Consulting the spec, that's effectively a request amounting to "here is an ID and a pre-shared secret", and a response with "here is a token that lets you access resources" - extremely similar to traditional authentication with a username and password.

Looking at it like that, you could use a limited subset of OAuth 2 for the sake of future-proofing your API in case it ever needs any of the other OAuth functionality. Or, if you already have some authentication layer based on username+password, you could potentially re-use some of that logic for this. In the case of Client Credentials, the two approaches appear essentially the same from a security perspective.

Now, one usability benefit of using OAuth 2 client credentials is that the client developers can use existing off-the-shelf libraries if they so choose, rather than being required to build a custom authentication layer in their client app. So for that reason, building a simple OAuth 2 client credentials workflow seems like a good approach.

  • 2
    OAuth2 is an Authorization protocol. It is not suited for Authentication. – Jacco Oct 16 '18 at 10:50
  • @Jacco Good point, and I think that nicely sums up my own feeling of "well, kinda, but only partly". Do you reckon it's worth editing that observation into this answer? – Ethan Kaminski Oct 16 '18 at 15:28
  • Give the prevalence of this misunderstanding of OAuth2, yes, I would definitely editing this observation into your answer. – Jacco Oct 17 '18 at 6:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.