REST Assured Authentication

REST Assured Authentication

In this tutorial, we’ll analyze how we can authenticate with REST Assured to test and validate a secured API properly.

In this tutorial, we’ll analyze how we can authenticate with REST Assured to test and validate a secured API properly.

1. Overview

The tool provides support for several authentication schemes:

  • Basic Authentication
  • Digest Authentication
  • Form Authentication
  • OAuth 1 and OAuth 2

And we’ll see examples for each one.

2. Using Basic Authentication

The basic authentication scheme requires the consumer to send user id and a password encoded in Base64.

REST Assured provides an easy way to configure the credentials that the request requires:

  .basic("user1", "user1Pass")

2.1. Preemptive Authentication

As we’ve seen on a previous post on Spring Security authentication, a server might use a challenge-response mechanism to indicate explicitly when the consumer needs authenticate to access the resource.

By default, REST Assured waits for the server to challenge before sending the credentials.

This can be troublesome in some cases, for example, where the server is configured to retrieve a login form instead of the challenge response.

For this reason, the library provides the _preemptive _directive that we can use:

  .basic("user1", "user1Pass")
  // ...

With this in place, REST Assured will send the credentials without waiting for an Unauthorized response.

We hardly ever are interested in testing the server’s ability to challenge. Therefore, we can normally add this command to avoid complications and the overhead of making an additional request.

3. Using Digest Authentication

Even though this is also considered a “weak” authentication method, using Digest Authentication represents an advantage over the basic protocol.

This is due to the fact that this scheme avoids sending the password in cleartext.

Despite this difference, implementing this form of authentication with REST Assured is very similar to the one we followed in the previous section:

  .digest("user1", "user1Pass")
  // ...

Note that, currently, the library supports only challenged authentication for this scheme, so we can’t use preemptive() as we did earlier.

4. Using Form Authentication

Many services provide an HTML form for the user to authenticate by filling in the fields with their credentials.

When the user submits the form, the browser executes a POST request with the information.

Normally, the form indicates the endpoint that it’ll call with its action attribute, and each input field corresponds with a form parameter sent in the request.

If the login form is simple enough and follows these rules, then we can rely on REST Assured to figure out these values for us:

  .form("user1", "user1Pass")
  // ...

This is not an optimal approach, anyway, since REST Assured needs to perform an additional request and parse the HTML response to find the fields.

We also have to keep in mind that the process can still fail, for example, if the webpage is complex, or if the service is configured with a context path that is not included in the action attribute.

Therefore, a better solution is to provide the configuration ourselves, indicating explicitly the three required fields:

    new FormAuthConfig("/perform_login", "username", "password"))
  // ...

Apart from these basic configurations, REST Assured ships with functionality to:

  • detect or indicate a CSRF token field in the webpage
  • use additional form fields in the request
  • log information about the authentication process
5. OAuth Support

OAuth is technically an authorization framework, and it doesn’t define any mechanism for authenticating a user.

Still, it can be used as the basis for building an authentication and identity protocol, as is the case of OpenID Connect.

5.1. OAuth 2.0

REST Assured allows configuring the OAuth 2.0 access token to request a secured resource:

  .// ...

The library doesn’t provide any help in obtaining the access token, so we’ll have to figure out how to do this ourselves.

For the Client Credential and Password flows this is a simple task, since the Token is obtained by just presenting the corresponding credentials.

On the other hand, automating the Authorization Code flow might not be that easy, and we’ll probably need the help of other tools as well.

To understand correctly this flow and what it takes to obtain an Access Token, we can have a look at this great post on the subject.

5.2. OAuth 1.0a

In the case of OAuth 1.0a, REST Assured supplies a method that receives a Consumer Key, Secret, Access Token and Token Secret to access a secured resource:

  .oauth(consumerKey, consumerSecret, accessToken, tokenSecret)
  // ...

This protocol requires user input, therefore obtaining the last two fields won’t be a trivial task.

Note that we’ll need to add the scribejava-apis dependency in our project if we’re using OAuth 2.0 features with a version prior to 2.5.0, or if we’re making use of the OAuth 1.0a functionality.

6. Conclusion

In this tutorial, we’ve learned how we can authenticate to access secured APIs using REST Assured.

The library simplifies the process of authentication for practically any scheme that we implemented.

As always, we can find working examples with instructions on our Github repo.

Thanks for reading ❤

Mobile App Development Company India | Ecommerce Web Development Company India

Mobile App Development Company India | Ecommerce Web Development Company India

Best Mobile App Development Company India, WebClues Global is one of the leading web and mobile app development company. Our team offers complete IT solutions including Cross-Platform App Development, CMS & E-Commerce, and UI/UX Design.

We are custom eCommerce Development Company working with all types of industry verticals and providing them end-to-end solutions for their eCommerce store development.

Know more about Top E-Commerce Web Development Company

What is REST? What are RESTful Web Services?

What is REST? What are RESTful Web Services?

This tutorial provides an introduction to RESTful web services and goes over what REST is as well as HTTP.

REST stands for REpresentational State Transfer. It is a popular architectural approach to create your API's in today's world.

You Will Learn
  • What is REST?
  • What are the fundamentals of REST APIs?
  • How do you make use of HTTP when building REST API?
  • What is a Resource?
  • How do you identify REST API Resources?
  • What are some of the best practices in designing REST API?
What Is REST?

The acronym REST stands for REpresentational State Transfer. It was term originally coined by Roy Fielding, who was also the inventor of the HTTP protocol. The striking feature of REST services is that they want to make the best use of HTTP. Let's now have a quick overview of HTTP.

A Relook at HTTP

Let's open up the browser and visit a web page first:

And then click on one of the result pages:

Next, we can click on the link on the page we end up in:

And land upon another page:

This is how we typically browse the web.

When we browse the internet, there are a lot of things that happen behind the scenes. The following is a simplified view of what happens between the browser, and the servers running on the visited websites:

The HTTP Protocol

When you enter a URL such as in the browser, a request is sent to the server on the website identified by the URL. That server then responds with a response. The important thing is the formats of these requests and responses. These formats are defined by a protocol called HTTPHyper Text Transfer Protocol.

When you type in a URL at the browser, it sends out a GET request to the identified server. The server then replies with an HTTP response that contains data in HTMLHyper Text Markup Language. The browser then takes this HTML and displays it on your screen.

Let's say you are filling in a form present on a web page with a list of details. In such a scenario when you click the Submit button, an HTTP POST request gets sent out to the server.

HTTP and RESTful Web Services

HTTP provides the base layer for building web services. Therefore, it is important to understand HTTP. Here are a few key abstractions.


A resource is a key abstraction that HTTP centers round. A resource is anything you want to expose to the outside world through your application. For instance, if we write a todo management application, instances of resources are:

  • A specific user
  • A specific todo
  • A list of todos

Resource URIs

When you develop RESTful services, you need to focus your thinking on the resources in the application. The way we identify a resource to expose, is to assign a URIUniform Resource Identifier — to it. For example:

  • The URI for the user Ranga is /user/ranga
  • The URI for all the todos belonging to Ranga is /user/Ranga/todos
  • The URI for the first todo that Ranga has is /user/Ranga/todos/1

Resource Representation

REST does not worry about how you represent your resource. It could be XML, HTML, JSON, or something entirely different! The only important thing is you clearly define your resource and perform whatever actions that are supported on it by making use of features already provided by HTTP. Examples are:

  • Create a user: POST /users
  • Delete a user: DELETE /users/1
  • Get all users: GET /users
  • Get a single user: GET /users/1
REST and Resources

A significant point to note is that with REST, you need to think about your application in terms of resources:

  • Identify what resources you want to expose to the outside world
  • Make use of the verbs already specified by HTTP to perform operations on these resources

Here is how a REST service is generally implemented:

  • Data Exchange Format: No restriction is imposed over here. JSON is a highly popular format, although other such as XML can be used as well
  • Transport: Always HTTP. REST is completely built on top of HTTP.
  • Service Definition: There is no standard to specify this, and REST is flexible. This could be a drawback in some scenarios, as it might be necessary for the consuming application to understand the request and response formats. There are widely used ones however, such as WADL (Web Application Definition Language) and Swagger.

REST focuses on resources and how effectively you perform operations on them using HTTP.

The Components of HTTP

HTTP defines the following for a request:

For the response, HTTP defines the:

HTTP Request Methods

The method used in a HTTP request indicates what action you want to perform with that request. Important examples are:

  • GET: Retrieve details of a resource
  • POST : Create a new resource
  • PUT: Update an existing resource
  • DELETE: Delete a resource

HTTP Response Status Code

A status code is always present in a HTTP response. Common examples are:

  • 200: Success
  • 404: Page not found

In this article, we had a high-level look at REST. We stressed the fact that HTTP is the building block of REST services. HTTP is a protocol that is used to define the structure of browser requests and responses. We saw that HTTP deals mainly with resources that are exposed on web servers. Resources are identified using URIs, and operations on these resources are performed using verbs defined by HTTP.

Finally, we looked at how REST services make the best use of features offered by HTTP to expose resources to the outside world. REST does not put any restrictions on the resource representation formats or on the service definition.

What is REST API? | Restful Web Service

What is REST API? | Restful Web Service

In this post "Restful Web Service", you'll learn: What is Web services, what is API, What is REST API, How REST works and Implementation of REST API

What is REST API? | Restful Web Service

A REST API defines a set of functions to process requests and responses via HTTP protocol.

REST is used in mobile application as well as in web applications.