Understanding Claims

Question

I'm trying to get up to speed with OpenId Connect, OAuth2.0, Security Token Service and Claims. Imagine a scenario with a large website with many areas and different functionality e.g. Customer, Order, Supplier, Delivery, Returns etc. My question is this – would I create Claims on the Token Server such as CanCreateCustomer, CanReadCustomer, CanUpdateCustomer, CanDeleteCustomer etc, i.e. effectively CRUD Claims for each main area/Business Object? This would lead to many tens but more likely hundreds of Claims. Or is my understanding coming up short?

Eccles

Answer 1

So fixing terminology, you mean "scopes", not "claims". Scopes are identifiers used to specify what access privileges are being requested. Claims are name/value pairs that contain information about a user.

So an example of a good scope would be "read_only". Whilst an example of a claim would be "email": "[email protected]".

You can send claims in the id token (or JWT), or/and have them available via the userinfo endpoint (if using the "openid" scope).

You can break scopes down per service, and have them as granule as you would like. Or have them as high level (read / write / admin). I would recommend having enough scopes to actively achieve the security principle of least privilege (basically: giving people what they need to do their job). You can use namespaces if you have a lot of scopes.

Seaquake

So, are scopes about authorizatoin, and claims abouts identity? If an oauth client requests a "read" scope, does that necessitate a certain set of claims being returned in the token(s)? – Laughton

Yeah, scopes, and claims are kind of about authorization (or individual permissions), and identity respectively. I don't think the returned claims for each scope are not really defined with in the OAuth spec. The Open Id Connect (Or OIDC) builds on the OAuth spec, and defines common scopes like "profile", and "openid" ref: auth0.com/docs/scopes/current/oidc-scopes – Seaquake

Answer 2

Your understanding is right, but you have a lot more flexibility in OAuth2.0 scopes (claims)

These scopes can be configured in any way for eg, in your case instead of creating individual scopes for each CRUD operation for each main area, you could create group scopes like

customer.read_write
order.read_write 

Etc, you can even go one level higher , by creating functionality level scopes, like

webportal.full_access
adminportal.full_access

Then in your application, after authentication, the authorisation can be done like,

ValidScopesIn({Scopes.WEBPORTAL_FULL_ACCESS, Scopes.CUSTOMER_READ_WRITE})
public void createCustomer(Customer customer) {
// your creation logic 
}

Aside

Answer 3

I think your understanding is largely correct. However, if I understand what you describe correctly it seems more of an authorization (OAuth) rather than an authentication (OIDC) problem, and as such you might have a look at how other OAuth resource providers define their scopes (not claims btw), for instance GitHub or Slack.

Zoospore

Answer 4

I would recommended that "scopes" be configured as URIs so that collisions do not occur.

As an example.

-jim

Siliculose