Imagine you are a tester having some knowledge about testing APIs either manually or using popular Java-based library for automation i.e. Rest-Assured. Your project manager approaches you and asks you to test and automate OAuth2.0 protocols being implemented by development team. What is the first thing that comes to your mind? Some of you may wonder what is OAuth 2.0, why is it being implemented and most importantly how can I test it. Having realised it is some form of authorisation, you will want to know more about its work flow and gather some technical details from your development team in order to write your test cases efficiently. This article will help you to give a quick, concise and practical knowledge about OAuth 2.0 and what it takes to test it using postman and write some automation scripts. This article aims at helping you understand OAuth2.0’s seemingly complex workflow and testing process in a simpler manner. So let’s get started.
What is OAuth 2.0
OAuth 2.0 is the industry-standard protocol for “authorisation”. It is neither an API nor a service. It is also not an Authentication protocol. OAuth is a standard that any application can use to provide client application with ‘secure access’. OAuth works over HTTPS and authorises devices, APIs, servers, and applications with access tokens rather than sharing credentials. Yes, OAuth 2.0 uses Access Tokens! Access token represents authorisation that help in giving access to resources on behalf of the end user.
Where have I used OAuth2.0 before
A lot of places. OAuth 2.0 exists almost everywhere these days. Do you remember visiting or registering at centralised hotel booking websites such as ‘Booking.com’, flight booking websites like ‘Skyscanner’, professional networking sites ‘LinkedIn’, some of great learning portals such as ‘Udemy’ or ‘Coursera’? If your answer is ‘Yes’ then you may have used this authorisation mechanism but with-out realising what it is called. Do you recall seeing a dialog shown below? That’s what I am talking about. This is an application asking if it can access data on your behalf.
Why use OAuth 2.0
There are many advantages of using OAuth2.0. First of all, they reduce complexity. You can mandate the authentication process to a third party that you trust, and never worry about user authenticity validation. Secondly, there is no need to store user credentials on company server. Why worry about loss of the sensitive data such as email or password and pay hefty penalty? Rather simply let the authorisation server take care of it.
Often it is thought that OAuth shares user credentials between applications but this is not true. In fact, userid or password is never shared from authorisation server instead it uses authorisation tokens to prove an identity between consumers and service providers.
Understanding workflow of OAuth 2.0
Let’s say you are developing an application that want to authenticate and login external users via their google account. So in this case, your application becomes a client for which google will assign a unique client id and client secret. You as a client must register your application with google in order to receive them. While registering you will also want to provide a callback URL so that users will redirected that URL upon successful authentication.
OAuth consists of 4 actors in the process of access delegation:
- Resource Owner (a system or user that owns private resources like email, photos etc.)
- Client (usually an application that wants to access these resources)
- Authorisation Server (This server receives requests from the Client for Access Tokens and issues them upon successful authentication and consent by the Resource Owner.)
- Resource Server (who stores user’s private resources and shares them with authorised clients).
While using OAuth2, the client (mobile app, desktop app or website) requests authorisation from Authorisation Server providing client_id and client_secret as identification. Authorisation server authenticates the client. After a user successfully authorises an application, the authorisation server will redirect the user back to the application with either an authorisation code or access token in the URL. Using the ‘access_token’ client then requests access to the resource from the resource server as shown the following diagram.
Authorisation server may not directly return an Access Token, for better security, sometimes an Authorisation Code may be returned, which is then exchanged for an Access Token. In addition, the Authorisation server may also issue a Refresh Token with the Access Token. Refresh token usually have longer expiry time than access tokens.
Part 2 of the post can be found here
Check out all the software testing webinars and eBooks here on EuroSTARHuddle.com
