Best Practice for granting API permission based on the caller's credentials

[#1]

What is the best practice for granting API permission based on the caller's credentials?

For example, suppose there is a /basepath/v1/items resource and I want only UserA can do CRUD operations on it while UserB can only GET it, how can this be achieved in Apigee?

Actually, I have a solution but not sure if it is the recommended ways:

1. Create two separate API Products, which contains the same API proxy for /basepath/v1/items

2. Following steps in https://community.apigee.com/articles/2514/how-to-restrict-api-resources-by-their-full-path-a.html, add different Resource Paths for different API Products.

[Abhishek_Subram]

Hi @Mark Tse,

I think we can use SCOPES to address your situation with a single product.

1. Create a product with 2 scopes - CRUD & GET
2. Create tokens for UserA with scope CRUD & for UserB with scope GET
3. Validate scope in your flows appropriately & provide access control

Thanks, Abhishek

[#3]

Hi @Abhishek Subramanya,

Thanks a lot for your reply. I did read about OAuth 2.0 scopes before - http://apigee.com/docs/api-services/content/working-scopes.

My followup question would be - if I open an API for user to obtain OAuth access token, is there any way I can limit UserA to request a token with CRUD scope?

Regards,

Mark

[DChiesa]

yes.

In the 3-legged flow of the oauth model, the user himself "owns" the data under management. The resource manager (backend service) manages data on behalf of the user. An example here is an email provider like gmail - they provide the service. But If I have a gmail account, I myself am the putative "owner" of the data. (put aside the specific terms and conditions that gmail makes people sign these days).

So, when engaged in a 3-legged flow, the user starts an app, and the app requests a token. The OAuth server (in this case Apigee Edge) redirects the app to an authenticate-and-consent experience, typically externally provided as a login page on a website. Using this web page the user authenticates and provides consent to the resource manager, agreeing that the app in question should be able to do what it is asking to do (view contacts list, search email history, or whatever). These actions, these "things the app is asking to do" are customizable for each API, and are known as scopes.

In one type of authn-and-consent experience, the authn server presents a webpage, and the user is presented with a yes or no decision: allow the app ALL of these scopes (whatever they are) or deny the app these scopes. In another type of experience, the user gets a set of checkboxes, and can individually specify the scopes the app should be granted. The latter is much more complex to implement, for the app designer, so the former is much more common.

After the user has authenticated and granted consent, at this point the authn server redirects the user web browser back to the OAuth Server (Apigee Edge) with some information, including the authenticated user id, the approved set of scopes, and possibly some other information - for example claims about the user, such as the company affiliation, the group membership, or the type-of-credentials the user used to authenticate.

Any or all of that extra information can be used to limit or adjust the scope granted to a token.

----

The standard model is:

- the app "knows" which scopes it needs to request

- the authn server presents the scopes to the user for approval (along with perhaps a human-language definition of those scopes)

- the user grants or denies the scope

- the oauth server issues a token with the granted scopes

But in step 2, your authn server can make a decision based on the authenticated identity of the user, to limit the list of scopes that the user is allowed to grant to a particular app. The authn server also may wish to limit the list of scopes based on the identity of the APP itself.

Or alternatively in step 4, the OAuth server could be coded to exclude certain scopes for certain users.

So it is possible. Whether this actually makes sense for you to do, might be worth a further discussion.