restful api authentication confusion with oauth2

Question

I did some investigation about restful api authentication. Most people pointed to Oauth2 for restful api authentication. I looked into some of resouces, especially this link https://developers.google.com/accounts/docs/OAuth2.

It seems to me Oauth2 is for a third party app to access users' data in google/facebook(or other data provider).

Our problem is that we own the data, we don't need to access our client's any third party data and our clients don't have to any third party data. We want to protect our api with some sort of authentication.

For our case what is the convenient technologies for our restful api authentication ? We will expose our api like this

 https://ourdomain.com/api/<endpoint>

Our clients can access a website first to register https://ourdomain.com and they should be able to get clientId and clientKey from our website for accessing apis. Our clients should be able to consume through some sort of authentication

Answer 1

Just to be clear with the original question:

OAuth2 needs at least a client and a server

OP was wondering how to secure a REST API, and why everyone is talking about third party authentication providers (Google, Facebook, ...)

There are 2 different needs here:

1 - Being able to secure a personal API (ourdomain.com)

Client             Server
Consumers  <---->  Your API

2 - Being able to consume a public API (For example getting a user's Google contact list)

Client             Server
You        <---->  Google APIs

OP actually needs the 1st: implement an OAuth2 server in front of its own API.
There are many existing implementations for all languages/frameworks on Github

Finally, here is one nice Oauth2 technical explanation, and I'm shamelessly taking one of its schemas here:

No I'm not working at Google, I'm just taking Google as a public API supplier example.

Answer 2

In oAuth 2.0, there are several types of grant types. A grant type is just a way to exchange some sort of credentials for an access token. Typically oAuth refers to 3rd party usage with a Authorization Code Grant. This means redirecting the user to the resource owner's website for authentication, which will return back an Authorization Code.

This clearly doesn't make sense for 1st party oAuth use, since you ARE the resource owner. oAuth 2.0 has considered this and included the Resource Owner Password Credentials Grant for this purpose. In this case, you can exchange a username and password for an access token at the first party level.

See https://www.rfc-editor.org/rfc/rfc6749#section-4.3 for more details.

Answer 3

If I understand correctly, what you need it similar to OAuth in a way that you do the exact same thing minus granting a 3rd party app access to a user's resources.

In OAuth, there is a central system that manages authentication and authorization by checking an app's credentials + user's credentials and dishing out authorization tokens. There are multiple endpoints that will accept these authorization tokens.

The tokens are basically encrypted strings that contain info about the user's credentials and some other info that might be needed by your app.

What you need (i believe) is a similar authentication endpoint, that the client hits with its credentials and gets a token.

So,
i) Create a registration form/console where a client can register and get his credentials. Have a look at this.
ii) Define a HTTP endpoint where the user exchanges his credentials for an access token + refresh token.
iii) The client can hit the resource endpoint with the access tokens to make authenticated calls to any of your endpoint.
iv) At the back-end you'd need a common service that verifies the tokens and extracts info from it.

PS - This is just a minimal system, there would be a lot of security considerations like what if some unauthorized app gets access to some client's access tokens.
You can find much information about CSRF attacks, noonces, timestamps and other methods of mitigating security concerns.