Previously On…
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.
Context
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:
Guidelines
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:
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 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.
What I mean with this title, is that is important to intercept and inspect your network traffic. E.g. HTTP requests that are created in the MVC application's code-behind cannot be intercepted from the browser. HTTP requests that happen in javascript however can be intercepted. Every piece of information that leaks to the browser in a token, body, or cookie can be used for an attack.
Outro
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.
