I want to make sure I’m understanding this properly. The doc states:
Access Tokens must never be used for authentication. Access Tokens cannot tell us if the user has authenticated.
But if we have an access token, doesn’t it mean the user has authenticated? Can we not assume that there has been a successful authentication when receiving an access token?
I’m curious about this as well… specifically regarding of what use the sub claim in the access token is. Can this be relied upon to identify the user that has some amount of authority… say there is a edit:owned_documents scope on the access token, could the sub claim indeed be used to decide which documents are indeed owned by a user and should be editable?
If not, I am seriously confused as to how/why the /userinfo endpoint can be used to get trusted information using the access token.
I’m just not sure I understand what the documents mean by “the user has authenticated”
and yes, I have read both
The problem with OAuth for Authentication
User Authentication with OAuth 2.0
And have not been able to come away with a concrete understanding of the issue.
Looks like we aren’t going to get a response on this… it must be self-evident from the articles provided, and I just cannot make the connection
I would ask well what’s the context? What your use case/scenario? Where are you receiving the access token from and what are you trying to do?
So a few terms came up… OAuth2.0 is an authorization framework. For an example, it can enable us to obtain (limited) access to some resource. So, depending on our case, we request the access token from the authorization server (API) and its able to do that by a few checks, one including whether we are authenticated. If all checks are valid then the authorization server provides an access token. The access token performs actions (by scopes it’s granted) and simply informs the API that this token is authorized to access the API (and perform actions). It doesn’t know anything further. It represents the authorization. Authorization is the process of verifying that you have access to something, who is allowed to do what.
Authentication is the process of ascertaining that somebody/something is who they/it claims to be. That is why we say access token is not used for authentication. To explore a bit more, A JWT must contain a “sub” (subject) claim identifying the principal that is the subject of the JWT. Two cases need to be differentiated: A. For the authorization grant, the subject typically identifies an authorized accessor for which the access token is being requested (i.e., the resource owner or an authorized delegate), but in some cases, may be a pseudonymous identifier or other value denoting an anonymous user. and B.
For client authentication, the subject must be the “client_id” of the client. If your access token has the audience sent to the Management API v2, then it can perform a call to the /userinfo endpoint. It can perform this action. This is why the API’s first thing to do is to validate the token (it does this in a few steps… 1.check that the JWT is well formed, 2. check the signature, 3. validate the claims, 4. check the app permission…) . Something like edit:owned_documents would only inform us it has access to the edit endpoint. The sub claim (the ID of the resource owner) can be the user ID for example, but what does this tell us? This alone, if at all, would not be enough.
Thank you for you answer @kimcodes.
OK I understand that a token alone is like a valet key, and can be used by someone other than the owner of the resource.
I do think the documentation is misleading when it states: “Access Tokens cannot tell us if the user has authenticated.”
In fact you can’t get an access token if you don’t authenticate first. Regardless of what happens to the access token later on.
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
Hey there!
Sorry for such delay in response! We’re doing our best in providing the best developer support experience out there, but sometimes the number of incoming questions is just too big for our bandwidth. Sorry for such inconvenience!
Do you still require further assistance from us?