401 unauthorized — Now is the time to let the Robot in
Any software nowadays needs to have some security control for access. APIs support several types of Authentication and today we are going to talk about two of them, Basic and Bearer with JWT.
The first thing we need to clarify is the meaning of Authorization and Authentication. This is easy.
Authorization is what you can do. Let’s say you have access to the White House but you are not authorized to enter The Oval room. Is that easy?
Authentication is who you are. That is, the guard at the entrance to the White House verifying your ID to see if you really are you.
The funny thing is that when you access your API without a token, with an incorrect token, or even with a token that is not authorized, the error that will return is always the “401 unauthorized”. Sometimes it is wrong because it should be “Not authenticated” — I don’t even know who you are.
Talking of these authorizations / authentications, there are several types with different protocols and forms. The simplest one is Basic Authentication, which is the basic “user” and “password” sent in the API header.
Let’s see using an example. To do this basic authentication we must send the credentials when creating the session in the API in the field “auth”, so all routes accessed from this API will have the “auth” already saved.
Our Robot is super smart and already understands that this API requires Basic authentication.
In the variables ${email} and ${password}, user information must be passed to access the API.
Let’s talk about Bearer
Bearer authentication (also known as token authentication) is a Schema for HTTP authentication (RFC6750).
Authorization: Bearer <token>
Bearer identifies resources protected by an OAuth2. The <token> must be a string. It represents a Server authorization issued to the client. In turn, the client must have its own mechanisms to identify and validate the Token.
But what is this “OAuth2”? Thiago Lima described it very simply:
“It is not just an authentication method, but a complete protocol with several security specifications.
It is extremely useful for the authentication and authorization process, which is why it is currently the most recommended method for the API scenario.”
In short words to access an API with this type of authentication you need to login first, and after you log in successfully the API will return a Token (which is that encrypted string).
This Token will be requested in all subsequent requests, so you should always send it in the Headers of your request, whether it is a GET, POST, PUT, DELETE or other less well known requests.
Some APIs have some specific rules with this token, and I have already had the pleasure of working with three different ones that made me hit my head a little and this is what I am going to explain today.
There is an example of an API that you only need to send the $ {token} in the header and everything is ready, as I did in the previous post with the API from Júlio de Lima.
In the answer os the Login Post Request, we take the token and store it in a variable. Then we set this as a Suite variable to be used in all other tests.
Then, in other requests we just need to pass the token to our variable in the header.
Impossible to be simpler than that, right? Oh yes, Basic is even easier.
I went through the following two experiences that I want to discuss here.
With some APIs you need to go beyond the Token plus some “little thing”. The examples I have are “JWT” and “Bearer” itself.
JWT is the security token itself (JWT = JSON Web Token) and the API can request that you send this information together with the TOKEN. We should remember to add this before the variable $ {token}. The easiest way is when you save the variable, you also write the word “JWT” so the word will never be forgotten. That way a FAIL will not appear on your screen.
And in other requests, just send the normal $ {token} as you can see there in the “Get Product”.
And the last example of the day is an API that requests to send Bearer along with the token, and you need to do the same as we did with JWT, you have to send the word “Bearer” before the $ {token}.
Another detail I want to show is that I used two different ways to “capture” the token of the answers. One of them was through “Set Suite Variable — $ {token} — ${resp.json () [‘token’]}, it is so simple because ${resp.json () [‘token’]} is already a string so just set it as a suite and continue using without fear.
And the other was through the keyword “Get From Dictionary” from Library Collections. In it you indicate which is the Dictionary in the case of JSON and indicate which is the separate field — token.
To validate that your token is being captured correctly in your log.html file you can check it being built as follows:
Another last-minute tip and especially for the learning phase is to use:
Log To Console My JWT Token is: ${token}
Thus, in the console, it is possible to validate that you are capturing the token correctly.
I hope you enjoyed the reading and most importantly that your doubts have been solved and you never again read a “401 unauthorized”.
Here I am also grateful to Antonio Montanha who had the patience to remove some theoretical doubts while I tried to write this post with these experiences that caused me some headaches.
References:
· Mayara Fernandes — Which is always a reference in the subject Robot Framework in Brazil
· QANinja
· https://www.brunobrito.net.br/jwt-cookies-oauth-bearer/
(Parte 3) Segurança em APIs RESTful
E aí vamos aprender mais sobre APIs Restful?thiagolima.blog.b
