Restricting API Access to User-Created Resources

authenticationrest

What is the best practice way to restrict access to particular resources based on ownership. For example, if Adam created several posts (collection: /posts). And I want Adam to be the only user able to GET these, how can I restrict another user, Eve, from retrieving Adam's posts from the data store?

I can force a user to authenticate, to access /posts/*, however I'm not sure what the best way is to implement ownership?

I could create an 'owns' connection between user and the entity, and have some business logic which checks the relationship once the entity is retrieved before returning a response to the requesting app, but this would entail an additional call.

Is there a better way to restrict access to entities based on ownership?

Best Answer

You are mixing two different topics: Authentication and Authorization.

Authentication

Authentication is the act of confirming the truth of an attribute of a single piece of data claimed true by an entity or as identification, which refers to the act of stating or otherwise indicating a claim purportedly attesting to a person or thing's identity, being the authentication the process of actually confirming that identity.

This answers the question: Who are you?

Authorization

Authorization is the function of specifying access control applying rights to a resource. More formally, "to authorize" is to define an access policy.

This aspect answers the question: What can you do with this resource?

As you can see, for you to do the Authorization phase you first must do the Authentication.

As an example, i'm authenticated right now in this site but i'm not authorized to delete your question. This is because i first passed on the Authentication phase - so the site knows who i am - and when i accessed your question, the site knows that i don't have admin rights, so it won't let me delete questions. - Authorization Phase.

In your scenario

As an REST API, you will have some form of authentication. This you have to choose for yourself, but in the end of it you have an authenticated user - or Principal. For more information on REST API authentication see the discussion on StackOverflow.

With the information of the authenticated user - that you can extract of the http request - all you have to do is check if the authenticated user has the authorization to do what it is requesting. In your case, check if he is the author of the resource he is trying to GET.

Related Solutions

RESTful Services – Implementing Role-Based Access to Resources

A method I have used to great success to expose the access level or roles the authenticated user has with respect to a particular resource is to expose it as HTTP verbs on the entity itself.

For instance requesting a list of all customers:

GET /customers
{
   customers: [
     {
        id: "/customers/1"
        allowed: ["GET", "UPDATE", "PUT", "DELETE"]
     },
     {
        id: "/customers/2"
        allowed: ["GET"]
     }
   ]
}

GET indicated read access UPDATE, PUT, DELETE would indicated Editor and or Admin access based upon the semantics of your API. If this sort of abstraction doesn't work in your case you could call the rolls out directly.

Additionally, you could provide a filter to the customers request

GET /customers?role=admin

Would return only the customers for which the authenticated user has the "admin" role.

Rest – Best solution to authorize that a user is only allowed to modify/act with their own resources in a REST API

I think there are two solutions in your list that fit your use case best; the read query before the update (solution 2) and sending an update token with the read request (solution 5).

If you're worried about performance, I'd decide on one or the other depending on how many reads vs updates to a resource you expect. If you expect way more updates than reads, then obviously solution 5 is better, because you don't need to do an additional database fetch to figure out the owner of the resource.

However, you shouldn't forget the security implications of giving out an update token. With solution 2, assuming authentication is secure, then updating a resource is probably also secure because you determine the owner of a resource on the server.

With solution 5, You don't double-check the claim the client makes, except that you check for a valid signature. If you're letting the update happen over a cleartext link (eg, no SSL), then only encoding the resource and user id in the token isn't secure. For one, you're opening yourself to replay attacks, so you should include a nonce that grows with each request. Also, if you don't encode a timestamp/expiration date in the update token, you basically give indefinite update access to anyone who has that token. Finally, if you don't want the nonce, then you should at least include an hmac of the fetched resource, so that the update token is only valid for the state of the resource as it was fetched. This makes replay attacks more difficult and further limits the damage knowledge of the update token can do, since the update token is only valid when the resource is in the given state.

I think that even if you're communicating over a secure link, adding a nonce (or at least an hmac of the state of the resource) and an expiration date for the update token would be a clever thing to do. I don't know the application domain, but you may deal with malicious users and they might wreck all kinds of havoc with the power of unlimited update access to their own resources.

Adding a nonce will mean an additional column per resource in your database where you store the value of the nonce you sent with the last fetch request. You can compute the hmac over the serialized json representation of your resource. You can then send your token not as part of the message body but as an additional HTTP header.

Oh, and I'd use a token, not a URL; in REST, the update URL for a given resource should be the same URL the resource was fetched from, right? I'd move all authentication & authorization-related stuff to the HTTP headers, e.g. you could provide the update token in the Authorization Header of the PUT request.

Note that adding a nonce that grows with each resource fetch will also require a database update (the new value for the nonce) for each resource fetch request (although you may get away with only updating the nonce when the state of the resource is actually changed, so it would be free from a performance standpoint), unless you want to keep that information in transient memory and simply have the clients retry when your server is restarted between a fetch and an update request.

A side note to your solution 4 (client side sessions): Depending on the number of resources your users can create, the session size might not be a problem. The client side session update problem might be fairly easy to solve, as well: If an update request to a resource fails because the resource is not listed in the session data you received from your client, but the user is correct, then you do a check in the backend whether the session data from that client is outdated. If it is, you allow the update and send back an updated cookie with the answer to the update request. This will only cause a database lookup when a user tries to update a resource from a client with outdated local session data (or when he is malicious and tries to ddos you, but rate limiting to the rescue!). However, I agree that solution 4 is more complicated than the others and you're better of with one of your other ideas. Solution 4 also has various security considerations you should take into account; storing this much authorization state on the client really needs your security to be watertight.