HTTP Basic Authentication + Access Token?

Question

I am developing a REST API that I plan on using with a web and IOS app. I intend for this API to be private for sometime (private meaning I only want my web app and ios app to access the api).

I have read about many different authentication methods but I am still to confused to select the appropriate authentication method for my API.

From what I understand, oAuth2 is for allowing users to login to your APP using other service providers so that you can access the data on the respective service provider. I am accessing the data in my own API so I believe this does not apply to me?

So, here is what I am thinking:

• 1) Use HTTP Basic Authentication to send the user/pass to the server.

• 2) Once the server validates the login, return an access token that will expire in x hours. This will allow me to simply store the token rather than the user/pass credentials.

I have Google'd this technique and haven't really found any info on this method which leads me to believe this is not a good way as I may potentially be trying to reinvent something?

What should I be doing? Is what I am looking for two-legged oAuth?

Answer 1

OAuth 2.0 has become the protocol of choice to secure web API's. It requires a user to authorize an application to access your web API.

You want your application to be the only one that can access certain API's. OAuth 2.0 allows doing just that.

In your authorization server, implement the Authorization Code Grant with client credentials required (not optional). Make it so that only your app (or a configured list op first party apps) can acquire the scope required to make those API calls. As long as you keep your client secret a secret indeed, your app will be the only one able to get an access token with the required scope. In the web API, ensure the scope is granted to the access token used to call the API.

Good authorization servers, such as The Identity Hub, will allow you to do just that.

Do not use the Resource Owner Password Credentials Grant. As the specification says:

The credentials should only be used when there is a high degree of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged application), and when other authorization grant types are not available (such as an authorization code).

This is repeated later on:

The authorization server should take special care when enabling this grant type and only allow it when other flows are not viable.

If the password credentials grant is available, any application can acquire a token by asking the user for a user id and password. This is exactly what you do not want.

The specification is very clear about the problems inherent to using passwords:

In the traditional client-server authentication model, the client requests an access-restricted resource (protected resource) on the server by authenticating with the server using the resource owner's credentials. In order to provide third-party applications access to restricted resources, the resource owner shares its credentials with the third party. This creates several problems and limitations

OAuth 2.0 was designed specifically to overcome some of the issues with using passwords:

OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner.

Furthermore, if your API wants to know the user (in addition to knowing the client app), it is impossible to abuse the Resource Owner Password Credentials Grant to authenticate the client (i.e. app) instead of the resource owner (i.e. user), as suggested by Florent Morselli.