HTTP basic authentication

HTTP basic authentication

Basic HTTP authentication works by sending the Base64-encoded username and password as a pair in the HTTP authorization header. The username and password must be sent for every HTTP request made by the client. A typical HTTP basic authentication transaction can be depicted with the following sequence diagram. In this example, the client is trying to access a protected RESTful web service endpoint (/webresources/departments) to retrieve the department details:

The preceding diagram represents an entire transaction. A client begins by requesting the URI, /webresources/departments. Because the resource is secured using HTTP basic authentication and the client does not provide the required authorization credentials, the server replies with a 401 HTTP response. The client receives the response, scans through it, and prepares a new request with the necessary data needed to authenticate the user. The new request from the client will contain the authorization header set to a Base64-encoded value of column-delimited username and password string, <username>:<password>. This time, the server will verify the credentials and reply with the requested resource.

As you have seen earlier, client requests can be generated from any application that can create HTTP connections, including web browsers. Web browsers typically cache the credentials so that the users do not have to type in their login credentials for every secured resource request. This is viewed as a deficiency of the protocol, since unauthorized access can take place with cached credentials, and there is no way for a web service to differentiate authorized requests from the unauthorized ones. Also, the login credentials can be easily deciphered as they are Base64-encoded. However, the intent of Base64 is not to secure the name-value pair but to uniformly encode the characters when transferred over HTTP. Because of these reasons, it is not recommended to use basic HTTP authentication for any application accessed over the internet. In general, we solve this potential security hole by using HTTPS (transport layer security) instead of HTTP, which we will discuss later in this chapter.











 

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

Jersey client API for reading chunked input

  Jersey client API for reading chunked input To read the chunked input on the client, Jersey offers the  org.glassfish.jersey.client.ChunkedInput<T> class. Here is a client example that reads the employee list in chunks, as returned by the server: //Other imports omitted for brevity import org.glassfish.jersey.media.sse.EventInput; import javax.ws.rs.client.ClientBuilder; String BASE_URI = "http://localhost:8080/hr-app/api"; Client client = ClientBuilder.newClient(); Response response = client.target().path("employees") .path("chunk").request().get(); ChunkedInput<List<Employee>> chunks = response .readEntity(new GenericType<ChunkedInput<List<Employee>>>(){}); List<Employee> chunk; while ((chunk = chunks.read()) != null) { //Code to process List<Employee> received in chunks goes here } //Close the client after use client.close(); Having discussed chunked output and input, we now wil...
Read more