Client Credentials Grant Flow + claims, oh my!

[ciaranj]

The outcome of the discussion in #67 (as I took it!) was that if I want to secure 'resources' that aren't owned directly by the authenticating end-user (which in effect is my main use-case, as I'm securing an API of services) I will need to use claims against the end-user.

I was directed to the ClaimsProvider to customise the claims provision logic in IdSrv3 where I can make choices based upon the subject (user), client, consented-to scopes and the request params.

My question (hopefully not too daft) is that in the case of the Client Credentials flow, there is no subject to retrieve the claims from, but if I'm authorizing in my API on claims, I (think) need some way of saying this client 'has these claims'.

However I don't want to always do this for this client, is it valid to assume that if the 'subject' passed into the IClaimsProvider#GetAccessTokenClaimsAsync is null the OAuth2 flow was ClientCredentials ?

Related, it feels as though I should be able to make decisions on what claims to allow based on the specific flow that granted the access token, e.g. I may choose to filter out certain claims if the access token is being granted as part of an implicit flow ?

Is this even a meaningful thing to do ? (sorry!)

[leastprivilege]

If the subject is null - there is no human involved.

We are not planning to have claims for clients. The client identity and scopes should be enough.

[ciaranj]

I guess my issue is actually over where the API has been called with an issued AccessToken.

I've pretty much convinced myself (with your help ;) ) that scopes are not an appropriate AuthZ mechanism for my services, as the 'authenticating end-user' does not own the resources that the authorization server is responsible for protecting. (There are one or two potentially appropriate resources that I may wish a user to be in a position to grant access to, but for the majority of the API, it is not appropriate to give the end-user any control over whether a given client can 'access' it)

With this in mind, I believe I need to do my AuthZ via claims (potentially just the subject identifier claim.)

Likewise I have a requirement where I would like to control the access certain clients (non end-user authenticated clients!) have to my API.

For the latter case it is obviously 'safe' to use scopes as I can restrict what scopes that client can request, however this would mean that I would have to split my logic in the API to test for either the case where;

• There is no 'sub' claim, and thus test scopes.
  or
• There is a 'sub' claim, go down the claims test route.

Alternatively, and I hate this idea, make a choice depending on the client_id (in the API!)

Because I'm not fond of (any) of these ideas, I figure I'll update my IDSrv3 ClaimsProvider to issue claims on behalf of certain configured clients, so the API can go back to just worrying about claims again.

Presumably when you say 'client identity and scopes should be enough' you mean the same :) ? (I had just been thinking that it might be useful within the ClaimsProvider to make a decision based on what flow had been used, but presumably I just configure different clients to manage that.)

(Update: #79 (comment) I see that the current design only supports 1 flow per client anyway, so passing the flow type would be pointless ;) )

[leastprivilege]

I am still not sure I follow - maybe you want to read the OAuth2 and OpenID Connect specs to find out more about the intent of scopes - which I think is much simpler than you think ;)

[ciaranj]

I've read ( http://tools.ietf.org/html/rfc6749#section-3.3 and http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims ) many, many times :/ My issue is not with their intent, which (as I read it) is with regards to restricting access to resources that are owned by the end-user.

For me;

• OIDC is being used as part of an SSO solution to authenticate an end-user through a particular client. (No issues here, I'm golden with that, identity tokens FtW!)

and

• ODIC is being used to provide an access token that a client can use to make calls to API endpoints that control data that the end-user does not 'own', they can potentially use the endpoints, if the API itself determines from the access token that the end user has the right to do so.

As far as I can tell, I as an end-user doing the OIDC dance, could potentially manipulate which scopes the client was requesting me to authorize and increase/change them prior to consenting.

This presumably is not a risk when the scopes are restricting access to the end-user's resources (because I'm only risking my own resource accesses), but in my scenario where the OIDC->Access token dance results in tokens for an API that I (as the end-user) do not own, and I cannot legitimately give consent to, this (scopes) would seem a poor choice to 'restrict access' and thus I'm limited to using claims (which the end-user cannot manipulate, without breaking the signature)??

I imagine there's some damn obvious missing piece of information that hasn't clicked into place for me, and for that I thank you for your patience!

[leastprivilege]

Can I close this?

[ciaranj]

Aye, I'm still struggling with conceptualising using OAuth to authorise non-end-user owned resources, but that's certainly not an IDSRV3 thing!