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.
-
1Here'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– DaisetsuOct 15, 2018 at 21:38
-
1OAuth is a depricated protocol. OAuth2 is its successor, but supports authorization. For authentication you need OpenId-Connect (which is build on top of OAuth2).– JaccoOct 16, 2018 at 10:47
-
1see also: Why is it a bad idea to use plain oauth2 for authentication?– JaccoOct 16, 2018 at 10:49
-
1OpenId-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.– JaccoOct 17, 2018 at 6:51
-
1Also, 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– JaccoOct 17, 2018 at 6:56
1 Answer
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.
-
2OAuth2 is an Authorization protocol. It is not suited for Authentication.– JaccoOct 16, 2018 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?– SoronOct 16, 2018 at 15:28
-
Give the prevalence of this misunderstanding of OAuth2, yes, I would definitely editing this observation into your answer.– JaccoOct 17, 2018 at 6:52