Authentication: It is the process of verifying the identity of the thing or user ,verify and identity will not only include the human users but also the software application, machine, etc.,
Why we need authentication?
Authentication is the first line of defense in application perimeter. when knowing who uses the system helps find what he can access and based on who is accessing we can allow or deny the actions which is limited to that person, also logging the activities helps in future research. In security point of view ,it helps to prevent data leakage.
Authorization
Authorization is the process of verify the identity, and ensure that the user who tries to access the resource is allowed to do within the system. After authenticating , the authorization controls access to resource based on the granted permission.
0 Auth 2.0
There are different types of authorization, In this blog we will explore some of the most important and commonly used ones.
Among the standard protocols designed to make your API more secure O Auth 2.0 is more widely used , which comes with multiple authorization flows.
Four types of grants that comes under O Auth:
Authorization code
password
client credentials
Refresh Token
Authorization code grant type:
we don't give information to the application but sign in through these accounts, most websites have this integration flow, which falls under the O Auth 2.0 mechanism.
how the flow happens , consider the application like booking tickets for flight or cinema or app like Spotify as soon as we try to access the application will show the screen when it will ask for login through third party sites like Google, Facebook, etc., like the screen below.
if we chose to go with google it will not ask for the password. what happens at the backend .
Core key parameters:
Scope: information or the permission what the server wants to give.
auth_url: Url where the authorization server will be send back.
Client_ID: The unique id for the app when connecting to the API server .
Response_Type: what response is expected from the server.(code)(like OTP).
State: Security terms, this value should match the application server to get the access token.
Redirect_url: after authorization where API server has to send you back.
Step1: Authorization Request:
authorization request will be send to the google API authorization server, which includes parameters like Client_ID, rediect_URL, response_type, scope, state.
Step 2:Authorization response: authorization grants permission with the code as the query parameter
it will be like this the one below
Step3:Exchange :The client then uses the code exchange, application with that code hits the resource server, server receive the code and validate whether it generate by google along with what profile it is attached and ask for API server checks for the code and provide the access token, and details or scope that application asks for. One important thing to note is nowhere the respective server provides the password.
it for getting the access token, when trying it into the postman, it will look like this entire url will hold all these parameter. When resource server asked for the token it it will cross check for the state and it matches then it returns the scope that asked for.
when we decode the url that is generated ,the parameter will look like the one below .
Refresh Token:
O auth token will expire at certain point of time , so if we configure with refresh token on grant type the client app can refresh and get new token instead of going through the entire workflow, it can simple use the old token from authorization.
Password:
Client app will directly take the username and password from the resource owner or end user ,uses them to communicate with the auth server to get token
Client credentials:
No end user or resource owner here, this workflow typically used for communication between microservice application, authorization will given the username and password of user to the client app, it will be store locally and the app uses them to get token when required to communicate with resource.
Implementing OAuth in Postman and Rest assured :Creating Repository using GitHub API :
I try to create a repository from postman in Github
API Endpoint: POST https://api.github.com/user/repos the header would be the Authorization as O-Auth (Acces-Token/Bearer Token) with content-Type :application/Json along with Request body as below ,
with Token generated from the GitHub
Go to profile Settings--> Developer settings-- > OAuth Apps and register the new application. By giving Application Homepage URL, authorization callback URL and you'll get a Client ID and Client Secret after registering, which are essential for the O Auth authorization flow, using these credentials OAuth token can be obtained through the authorization flow.
but to access GitHub API, i have generated personal access Token, to check the flow
Profile Setting-->Developer setting-->personal access Token-->Generate Token-->Token
after generate from there in Postman to the request setting the Authorization to OAuth and setting the Token under the Token value then trying to send the request i was able to create a repository from the postman. you can create a GitHub OAuth app by registering it by following the below steps
This is how O Auth works in postman, same way in Rest Assured O auth method works with the below steps
@Test
void OAuth2Authentication()
{
given()
.auth().oauth2("paste the token generated from the developer settings")
.when()
.then()
.statusCode(200)
.log().all();
}
}
(Note : ensure to replace you token to check for the repository of yours , generate the token through developer setting of GitHub profile setting)
Bearer Token:
Basic Auth :
Basic authentication is very easiest way to protect API. It is a part of standard HTTP specification and authorization header is used ,it is used like "Basic encoded user: password " ,Https(TLs) must be used along with basic .When user sends the credentials to API server in the header , the data in authorization header is a Base64 encoded string ,this format of string is used in password column, the server receives and it decodes the value then checks for user and password matches and returns 200 ok if not 401 unauthorized. How to perform in postman and Rest Assured we will see.
Drawback:
Credentials in clear text may lead to third party attack .
for every resource call credentials has to be sent. session management is required to avoid that.
Preemptive Authorization:
First step of Basic auth is similar in preemptive , sends the authentication credentials in the form of basic auth header like the one below
avoid the need of waiting to server first request is sent to the server. Same like Basic auth username and password should be sent for every request.
Digestive Authorization:
Digestive authorization relies on hashing. First step of this remains same as Basic authorization, client sends request, two more values will be included : one is nonce(Unique number) and another one is Qop (Quality of protection). Generally Basic authentication uses the Base 64 encode, in digest MD5 hashing i.e., the hash value would be send and it is the one way function. Hash is calculated with combination of username ,password and realm then Uri and HTTP method all together the value would be calculated, nonce value would be keep on changing to prevent the replay attack so incase of hackers intercepting has value gets expired it is used.
API Key and API secret:
API keys are passwords to access an authentication credentials, basically every website requires API Key
Though it is not list among the HTTP authentication schemas, but it is used widely, it is very simple generated during the first login or signup it is used as replacement for username and password, request can be sent without username and password the server will give response when using API Key, it is fetched from account setting page and it is possible to delete. Username and password are string meant for human API Key and secret are meant for applications and machine not for human. It is passed as header or query parameter and in some cases in request body. Header method is preferred as it can be misused when used in query params. I t is not secure as O Auth mechanism. API Key identifies the API customer client ID and Client key, but idea is same as client is same as user like Basic auth username password or like token authentication. API secret is the E-signature of the user, with digital signature API key will be send unlike basic auth where credentials will be send. Using hash function, API secret signature will be created .
API in combination with secrete used in authentication, and also used in getting Token from API provider, it is used for usage analytics, that is every time the consumer invokes the API , log and analytic entry is created, this helps in understanding the API usage.
in both ways like header and in query parameter i have tried giving the API Key in Rest assured. and below this the implementing API Key in postman where i have set the auth type to the API and given the key value .
Conclusion:
In this digital world securing data is challenging , and ensuring accessing user is eligible to use the resource provided , everything can be controlled through proper authorization. Proper authentication is the key to control the access and safeguarding the sensitive information . The above methods provides various level of security by implementing the authentication methods discussed like O Auth, Basic , API Key etc.,selecting based on the application and the level of security will help to secure the APIs.
Happy Securing!
Thanks for joining me in exploration of Authentication and Authorization methods.