OAuth 2.0
OAuth2.0 is an industry standard that enables re-use of user resources across different unrelated entities(services) with the consent of the resource oner. This is made possible by the keeper of a user resource acting as a authorisation server which authorises the requesting entity to access resources of a user. The requesting entity receives a access token from authorisation server, which it has to present to resource server when requesting to read or edit a resource. Specification at https://datatracker.ietf.org/doc/html/rfc6749 is worth a perusal.
OpenIdConnect
OpenIDConnect protocol is built on top on OAuth2 framework and provides a REST API to fetch the profile information of a user. It has been detailed in https://openid.net/specs/openid-connect-core-1_0.html. The picture below illustrates the steps to retrieve user profile information from resource owner through OpenId Provider. Providing a BFF is of course an implementation decision and not mandated by specification. In Step
ID Token
Is a JWT token that conveys to the relying party that the user was successfully authenticated and the duration for which it is valid. It does provide the user data as claims but does not guarantee the freshness of data./userinfo endpoint
Is used by relying party to fetch user information by presenting the access token that was issued by OpenId provider. It enables the relying entity to retrieve user's profile in a REST style, without requiring the user to share sensitive information such as password etc. The specification supports GET or POST /userinfo endpoint. The access token could be a JWT or an opaque token. If the token is valid(more on this later)the user profile information then shall be provided as claims in the response. It is always upto the BFF/Resource server to provide the request information. In case it choses not to provide or information is missing the claims is simply excluded from the response. An example of GET request and returned response is shown below:
GET /userinfo HTTP/1.1 Host: server.example.com Authorization: Bearer SlAV32hkKG
HTTP/1.1 200 OK
Content-Type: application/json
{
"sub": "23642801",
"name": "Herr Jane Doe",
"email": "janedoe@example.com",
}
Access Token
Access tokens may be issued in either JWT or opaque form, depending on the authorization server’s configuration. When an access token is a JWT, the resource server can validate it locally by verifying its signature and required claims (such as iss, aud, and expiration). If the token is valid and contains the necessary claims, the resource server may use those claims to authorize the request and return the protected resource.
When an access token is opaque, the resource server cannot validate it independently. Instead, it must call the token introspection endpoint of the authorization server that issued the token to determine its validity and associated metadata. Once validated, the resource server can authorize the request and return the appropriate protected resource to the relying party.
Scope vs Claims
OAUTH2 is a Role Based Access Control(RBAC). Normally, Roles are associated with users such as Admin, Developer etc. However, in case of OpenId Connect the relying party requests the permission to read on behalf of the user. Hence, in order to keep the difference the use of Scopes to request claims was adopted.
Security pitfalls and how to navigate them
Some mistakes in implementation could lead to OpenId Connect flow being exploited. It is better to be aware of such scenarios and prevent them altogether.
At the BFF / Resource Server:
Failing to ensure that the presented token is a valid access token issued for that resource server (e.g., by not validating aud, token usage, or issuer) can allow an attacker to replay a stolen ID token against the API. This may result in unauthorized access to user profile or protected resources.
At the Relying Party:
Failing to verify that the sub claim returned by the /userinfo endpoint matches the sub claim in the ID token can lead to identity substitution attacks, where profile information belonging to a different user is incorrectly associated with the authenticated session.
What next?
In this blog -[https://dev.to/mumbocoder/build-userinfo-endpoint-using-spring-32n4-temp-slug-5567840?preview=fe467a0664e4e9c2cd3bd79acaa9c2242297369b7599c2087fc997ea5f1992890d02468f1aec988c42a9bb8f3ab72edf02e2d25c3fff23f7e069cf44], we shall implement /userinfo endpoint in a Spring Boot application.
Top comments (1)
Good summary thx