In my previous post, I zoomed in on my assignment. The development is about the creation of a registration of a user, using Auth0 authentication flows, actions,... . My responsibility is the creation of a BFF for the front end using Asp.net 6. I mentioned in that post the usage of id tokens and access tokens.
Due to the nature of my assignment, it is necessary to understand the Oauth2 authentication flows. I will not create another post about these flows. I used the following materials to understand it:
Wesley Cabus has shared his wisdom with me regarding those guidelines. I want to spread the word about what I learned.
Tokens should be kept as small as possible
The OAuth2.0 specification does not define anything on this topic.
However, I want to explain why this is important:
There are several authentication flows defined in the specification. One of them is regarded as a very insecure one: Implicit Grantflow. In that flow is the access token part of the URL. An URL in a browser has a limited size. Not due to the HTTP specification, but due to browsers implementing that specification.
When storing or using the access token with cookies, know that a cookie is limited in size.
From a security standpoint, know that an access token can be decoded using jwt.io. Not all access token follow that JWT protocol, but can be opaque as well. When you add sensitive information in a token (e.g. email), that information can be used in spoofing attacks. This technique is used a lot to get access to a victim's computer.
Instead of adding data in a token, call the user info endpoint using the access token to gain personal information.
Business information should be put in the HTTP request Body
Do not use the access token to transport information. An access token is used to see if the consumer gets access to the API, not for transporting data.
When you work with sensitive data, still use the HTTP Request body.
To protect yourself from man-in-the-middle attacks: make the body tamperproof. Encode the body using e.g. JOSE protocol. Using the JOSE protocol, you can validate the information with the signature provided. E.g. An identity provider that uses this technique is ItsMe.
You can also encrypt the body, so only the receiver can read it. Read here for more detail.
An id token is a proof that the user is authenticated
When receiving an access token, it means that the consumers have access to an API. This does not mean that the caller is authenticated. That is not part of the OAuth2 protocol. For that, we have OpenID Connect. Receiving an id token is proof that the user says who he is.
An id token should not have much information. Use the user info endpoint to request the data.
When you supply an id token, you need to supply the challenge or ‘nonce’. Using that, the API can verify that the id token is not tampered with.
An access token should not be used as an id token
According to the Oauth2 specification, an access token should be handled as just some random characters. Use the endpoints defined in the Oauth2 specification to verify the access token. To work with user information, request it from the user info endpoint or if you have to, use the id token.
In an access token, access only claims that the API uses to check if the caller is authorized for accessing the requesting endpoint. E.g. the email claim: only persons from some domain can use this api and/or operation.
Be aware of what information lives where
It is hard to guard these guidelines. I have to be mindful of them. I must not let my guard down. I do see it as a positive note that I challenge my colleagues on this subject. I can only hope that other people will see this also as positive. Security is becoming more important. Databreaches.net gives an overview of breaches that have happened.
Do you like the guidelines above? Do you put these in a place where you work? Why or why not? I am curious. You can find me on Twitter and LinkedIn.
Did you find this article valuable?
Support Kristof Riebbels by becoming a sponsor. Any amount is appreciated!