CODEWITHSUNDEEP
apirestauthenticationoauth-2.0authorization
Lewis Chadwick
Lewis Chadwick

Reputation: 41

Multiple authentication levels in a RESTful API

Scenario

We are building a new RESTful API for our web application. This API will serve our mobile applications, our web application and authorised customers.

We are using Apigility to build the API and are making use of the OAuth2 implementation it provides.

Currently, our web application relies on a users table, with permissions assigned to each user. These users simply log-in using a web form, and the session is then stored and appropriate permissions checked upon access.

We want to be able to authenticate API access (such as our web app, and authorised customers), so no unauthorised access to the API can happen. However, we also want to authorize the permissions at a user level, therefore some sort of user authentication must also happen as well.

Any authorised access to the API may use a different user, so relying on a single user per client will not work, especially since the permissions are on a per user basis. We also do not want any user to be able to use the API without prior authentication, so wanted to avoid adding every user as a client to OAuth2.

For example:

The web app is authenticated with the API with two users using it:

UserA has user management permissions

UserB does not have user management permissions

Therefore, UserA can POST to /users and receive a 200 OK while UserB should receive a 403 Forbidden.

What we have tried

We have created an example application, and have successfully set up authentication using OAuth2 for the high-level clients and can make calls as expected. But we have not been able to create an authorization model for our users based on this.

We though adding a custom HTTP header with a user token that is provided after an authenticated call to /user/login. But we are not sure if this is the correct method.

The question

How can we both authenticate the high-level clients (such as our web app, or authorised customers) but then authorize access based on the user actually using the system?

Upvotes: 4

Views: 3081

Answers (2)

jwilleke
jwilleke

Reputation: 10996

OAuth has no concept of Identity.

You should look into using OpenID Connect which is a profile on top of Oauth 2.0.

Upvotes: 0

phalt
phalt

Reputation: 1244

You have a few options available to you:

Token-level permissions

You can provide different tokens for each user account, and tie permissions to the token. This runs the risk of the wrong tokens being mixed up with the wrong users. However, this also has the advantage of not having to maintain a user<->token relationship, as the permission is decided at the token level. How you decide which token to generate can be tricky.

User-level permissions

You can tie a user account to a token and that user can then be given read/write permissions. This reduces the risk of a user having a wrong token as they're linked. With this method, you can use the same method of token generation for all user accounts as the token is ignorant of the permission, but does allow them "access" to the API (thus preventing unauthorised access).

I've deliberately avoided mentioning specific types of authentication tokens, as these two concepts can apply to most of the popular choices on the web (token-based, OAuth based).

Upvotes: 2

Related Questions