RESTful Java Web Services 3rd Edition-Bogunuva Mohanram Balachandar

  Securing RESTful web services with OAuth OAuth is an open standard for authorization, used by many enterprises and service providers to protect their resources. OAuth solves a different security problem from what HTTP basic authentication has been used for. The OAuth protocol allows client applications to access protected resources on behalf of the resource owner (typically, the application user). If we look at the history of this protocol, OAuth version 1.0 was published as RFC 5849 in 2010. Later, the next evolution of OAuth, version 2.0, was published as RFC 6749 in 2012. Note that these two versions are different in their implementations and do not have many things in common. In this section, we will explore what the OAuth protocol and its details are. We will also discuss  accessing OAuth-protected RESTful web APIs from  a RESTful web service client. Understanding the OAuth 1.0 protocol The OAuth protocol specifies a process for resource owners to authorize third-p...

  Using JWT to secure RESTful services We will now see how to secure RESTful services using JWT. Let's take the HR service developed in the previous chapter for this purpose.  For illustration purposes, we will be abstracting the authentication as part of  HRService . In a real-life scenario, the authentication service will be deployed in a separate server. The authentication function will validate the user credentials and respond back with the JWT token for valid users; otherwise, it sends an unauthorized status in response, as follows: /** * Performs authentication of the user and generates JWT Token * * @return JWT Token in the Response */ @POST @Path("/login") @Consumes(APPLICATION_FORM_URLENCODED) public Response authenticateUser(@FormParam("login") String login, @FormParam("password") String password) { try { // TO-DO Authenticate the user using the credentia...

  JSON Web Token (JWT) overview JWT is self-contained and secured compared to the session ID, as it is digitally signed.  JWT consists of the following building blocks: Header : This contains the token type and hashing algorithm Body : This contains the reserved or custom claims, which serves the user verification details Signature : This contains the cryptographic signature made out of the encoded data and private key Here is a graphical representation of the JWT: For more details on JWT, refer to the JWT specifications at  https://tools.ietf.org/html/rfc7519 . 

  JWT authentication With HTTP being a stateless protocol, following HTTP authentication means that  the client has to be authenticated with its credentials  for every request . For stateful applications,  this becomes an issue, as the user will be prompted to log in for every action they perform.  For example, once the user logs in via a shopping cart application, he/she may proceed with choosing the selected items and checking out until he/she is done with the shopping. To handle such scenarios,  the legacy solution was to implement session-based authentication,  which uses server sessions to maintain the authenticated state of a client. In session-based authentication,  after the authentication of the user, a session ID is created by the server and sent in the HTTP response using cookies,  and the  same is passed along with every subsequent request to the server . So, until the user logs out of the application or the  session exp...

HTTP digest authentication To overcome the challenge with using clear text login credentials in HTTP basic authentication, the cryptographic hash of the login credentials are used for HTTP digest authentication. The client sends a one-way cryptographic hash of the username, password, and a few other security-related fields using the MD5 message-digest hash algorithm. When the server receives the request, it regenerates the hashed value for all the fields used by the client to generate the hash and compare it with the one present in the request. If the hashes match, the request is treated as authenticated and valid. To follow the steps of configuring the digest authentication realm in the GlassFish server, refer to  Chapter 2, Administering User Security in GlassFish Security Guide. If the client application uses the Jersey framework implementation, then the API to invoke the RESTful web services secured via the HTTP digest authentication looks like the following code snippet: //Res...

  Building JAX-RS clients with basic authentication A normal client-server transaction can follow two scenarios of basic authentication. On one hand, a client submits a request to the server without any authentication credentials (as depicted in the previous sequence diagram). On the other hand, a client submits a request to the server with the authentication credentials. Let's take a closer look at these two scenarios. When a client submits a request without the authentication credentials, the server responds back stating unauthorized access with an HTTP error code of  401 . If the request is executed from a web browser, users see the ubiquitous  Authentication Required  browser popup, as shown here: Users can then supply the valid credentials to complete the request. Note that the web browser keeps track of the 401 response and is charged with sending the proper authentication credentials back with the original URI. This makes the transaction seamless for the users...