Thanks for the response @kimcodes
So, yes… like benji, I understand that the authorization token is like “a valet key” that can be used by someone other than the owner of the car/resource, but the valet key has a built in indicator on what car it will allow the non-resource-owner, the valet to use… the car that it will start… there is (approximately) a 1-to-1 correspondence between car and key.
Is there anything like that built in to the OAuth2 standard?
I was under the impression that the sub claim was meant to be part of the mechanism that which the resource server could use to identify which resource owner the authorization was granted by so that it could appropriately release access. Surely a scope of edit:document means every last document in the system in very few cases? Or put another way, I thought a JWT token with a sub claim of “Joe” and a scope claim of “edit:documents” authorized the bearer of the token to edit all the same documents that Joe can.
However, you state
Which confuses things. I take this to mean that if Joe authorized Bill to edit his documents, then the sub field could (perhaps even should) contain “Bill”. Is that correct? If so, then how is the resource server to know that the bearer of the token (Bill) should be allowed to edit Joe’s documents and not Bill’s? Is that outside the scope (excuse me for overloading the word) of the JWT standard and to be negotiated/defined by the resource server through custom claims? Are scopes supposed to be defined to be rich enough to entirely and unambiguously determine the authorization level of a token? On The Nature of OAuth2’s Scopes seems to disagree.
If the sub field doesn’t identify the resource owner, the person being authenticated in order to provide authorization, then I can totally understand how the authorization token provides no guarantees about what authentication has happened.
So let me get specific.
I’m helping to develop an API… it would be considered the resource server. We inspect JWT authorization tokens in requests to help determine which resources should be accessible in a request… the sub claim is used for this. The API is currently used by only one web application front end… this web application gains authorization tokens on behalf of a user using an Auth0 “Single Page Application” and includes them in the requests made to the API. The API and the webapp trust each other (belong to the same organization), and they trust the Auth0 authorization provider used by the web application (the API validates the iss claim represents the endpoint of the Auth0 tenant we set up) since it is exclusive to the same organization and there is no involvement of external (Social or Enterprise) identity providers, and no custom database connections.
Is the API using the sub claim as an indicator of authority proper in this case? In what situations would these use cases begin to break down? Connecting to other identity providers via Auth0? We may need to use Enterprise SSO in the future. Using other Authorization providers? We are not interested in this at all (though who knows what requirements customers will raise in the future).
We have already run in to an issue via trying to start using Auth0 “Machine to Machine” applications because in this case, the sub field is different, and we don’t map these to users in the system. We probably could… and treat “machines” as just other types of users, but we are leaning to having a different permissions model… and understanding the format of the different sub fields (auth0|xxxxxx for authorizations presented by SPAs, and xxxxxx@client for authorizations presented by MTMAs) we can select which permission model to use… but still the sub claim is the top-level “key” driving authority checks.
Then what is enough? I don’t think we are doing anything revolutionary or novel, but I find it hard to find explicit guidance and recommendations.
Thanks so much for your time and apologies for the long post
Steven