Securing RESTful Web Services

 Securing RESTful Web Services

As RESTful web services use the HTTP transport protocol for communication, they are equally vulnerable to security risks observed with web applications. Often, the development of RESTful web services is focused on the functional requirements, and the security requirements get overlooked. As a best practice, a RESTful web service must be designed considering the security requirements to ensure that it is made bulletproof from security threats or attacks.

In this chapter, you will learn the different ways of securing RESTful web services from a development standpoint, and you will learn the applicable best practices. The following topics are discussed in this chapter:

  • HTTP basic authentication
  • HTTP digest authentication
  • JWT authentication
  • Securing RESTful web services with OAuth
  • Authorizing the RESTful web service accesses
  • Input validation
  • Best practices for securing RESTful services

Securing and authenticating web services

Security on the internet takes many forms. In the context of RESTful web services and this book, we are only interested in two forms of security—1.securing access to web services 
2. and accessing web services on behalf of the allowed users.

Security on the internet takes many forms. In the context of RESTful web services and this book, we are only interested in two forms of security—securing access to web services and accessing web services on behalf of the allowed users.

What we accomplish with securing web services is the calculated control of resources. Even though most web services are publicly available, we still need to control the data access and traffic throughput. We can do both by restricting the access through subscription accounts. For example, the API access can be limited based on the number of queries a registered user could execute daily. Similarly, many other API vendors restrict the access of their APIs.

Security has two essential elements:

    Authentication: This involves verifying the identity of the user who is tryingto access the application or web service. This is typically performed by obtaining the login credentials and validating them against the user details configured on the server.
  • Authorization: This involves verifying what an authenticated user is permitted to do in the application or service.

In this chapter, we will take a look at the various approaches for authenticating and authorizing RESTful web services. We will start with the simplest mechanism among all of them. 



Comments

Post a Comment

Popular posts from this blog

Understanding the JAX-RS resource life cycle

Image
Understanding the JAX-RS resource life cycle The following diagram depicts the sequence of actions taking place on the server when a client invokes the JAX-RS RESTful web service: For an incoming REST API call, the container identifies the Java servlet configured for handling the REST API calls by parsing the URI, and then delegates the request to the designated servlet. The servlet initializes the JAX-RS runtime and kicks off the RESTful web service request processing cycle for the REST API call in the following sequence: The runtime executes prematching filters ( ContainerRequestFilter  with the  @Prematching  annotation), which happens before resolving the resource method. The prematching filters are useful if you want to influence resource method resolution. The next step is to identify the resource method for serving the request. After the resolution of the resource method, postmatching filters are executed (filters without  @Prematching ). Postmatching filters ...
Read more

Generating a chunked output using Jersey APIs

  Generating a chunked output using Jersey APIs A chunked response means that instead of waiting for the entire result, the results are   split  into chunks (partial results) and sent one after the other. Sending a response in chunks is useful for a RESTful web API if the resource returned by the API is huge in size. With Jersey, you can use the  org.glassfish.jersey.server.ChunkedOutput  class as the return type to send the response to a client in chunks. The chunked output content can be any data type for which  MessageBodyWriter<T>  (entity provider) is available. When you specify  ChunkedOutput  as the return type for a REST resource method, it tells the runtime that the response will be chunked and sent one by one to the client. Seeing  ChunkedOutput  as the return type for a method, Jersey will switch to the asynchronous processing mode while processing this method at runtime, without you having to explicitly use  A...
Read more