I'm recently studying OAuth2.0 RFC, and I am confused with its meaning of authentication.
From The OAuth 2.0 Authorization Framework, the terms refer to RFC 4949:
Certain security-related terms are to be understood in the sense
defined in [RFC4949]. These terms include, but are not limited to,
"attack", "authentication", "authorization", "certificate",
"confidentiality", "credential", "encryption", "identity", "sign",
"signature", "trust", "validate", and "verify".
From Section 1.2 Protocol Flow, it describes that client will authenticate by presenting an access token:
(E) The client requests the protected resource from the resource
server and authenticates by presenting the access token.
(F) The resource server validates the access token, and if valid,
serves the request.
From RFC 4949, it states that
$ authenticate
(I) Verify (i.e., establish the truth of) an attribute value
claimed by or for a system entity or system resource. (See:
authentication, validate vs. verify, "relationship between data
integrity service and authentication services" under "data
integrity service".)
$ authentication
(I) The process of verifying a claim that a system entity or
system resource has a certain attribute value. (See: attribute,
authenticate, authentication exchange, authentication information,
credential, data origin authentication, peer entity
authentication, "relationship between data integrity service and
authentication services" under "data integrity service", simple
authentication, strong authentication, verification, X.509.)
...
An authentication process consists of two basic steps:
- Identification step: Presenting the claimed attribute value
(e.g., a user identifier) to the authentication subsystem.
- Verification step: Presenting or generating authentication
information (e.g., a value signed with a private key) that acts
as evidence to prove the binding between the attribute and that
for which it is claimed. (See: verification.)
How OAuth access token authentication complies with the meaning from RFC4949? To my understanding, presentation of the access token should be regarded as Verification step, then which part of it would be regarded as the Identification step?
I would also like to verify if my understanding is correct, given two examples,
I have an api that retrieves user information /users/:id, given the access token is also presented. In this case - (a) the query param :id is the claim and access token is the proof that client is authorized to retrieve the corresponding information.
I have an api that retrieves user information /users, and server will check who is the resource owner of access token and return corresponding information. In this case, does only validation against the access token happen because there is no claim from the client request? Or the access token itself has implicitly made a claim?
API VIEWPOINT
OAuth is primarily about protecting data. The viewpoint we are discussing is that of an API, which trusts requests when it receives a verifiable JWT access token and allows access to data. You could call this either authentication or verification.
APP VIEWPOINT
These days, front end apps use OpenID Connect and receive an ID token after authentication, as proof of the event. Note that there are many ways to authenticate and neither apps nor APIs have to deal with that - they just use tokens instead.
API AUTHORIZATION
I like to think of this as 3 levels:
Level 1: The API first verifies the digital signature of a received access token. This is done using a public key that the API trusts. If this fails a 401 error is returned. See this example code.
Level 2: The API then trusts the JWT's payload and next checks scopes, to avoid obviously invalid calls, eg a JWT with reports scope should not be able to call a payroll API.
Level 3: The API then uses claims from the JWT to enforce business rules, eg a European user with payroll rights might only be allowed to view salary details for European employees.
API URLs
When designing URLs, generally aim to include secure values such as user ID in the JWT access token as claims, rather than in URL path segments that could potentially be changed by a man in the middle.
These examples would both get the user identity from the JWT: