The simplest definition of authentication is the process of verifying the identity of a user; authorization is the process of verifying what an authenticated user can do. For example, when we log in as a user on our computer, we are granted access, allowing us to execute actions with the available resources (this includes files, applications, and so on).

In the applications that we create, authentication is the process of validating access to the application, and authorization is the process of protecting our resources, like pages, web services, databases, files, queues, and so on. During the authentication process, we validate the identities of those using the application. Authentication includes processes such as preventing to our application before providing valid credentials, multi-factor authentication (such as a secure image), one-time password (OTP), tokens, and more.

With regards to implementation, we already created a few application examples in previous chapters using Spring Security, which is an extensible framework that can be used to secure Java applications. Spring Security can be used to handle authentication and authorization, as well, using a declarative style that is not intrusive to our existing code.

Today, there are several identity industry standards, open specifications, and protocols that specify how to design an authentication and authorization mechanism, including the following:

• Basic authentication: This is the most common method, involving sending usernames and passwords with every request. We already implemented this method with Spring Security in our banking app example, which we used in Chapter 10, Containerizing Your Applications, Chapter 11, DevOps and Release Management, and Chapter 12, Monitoring.
• JSON Web Tokens (JWT): This is an open standard that defines how to establish a secure mechanism to securely exchange messages (information) between two parties. There are several well-tested libraries to use here, and we created an example of this in Chapter 4, Client-Server Architectures. The sequence can be illustrated as follows:

As explained previously, the preceding sequence diagram can help us to understand the process of token validation. For authentication, the clients should send their credentials to the server, which will respond with a token in the form of a string. This token should be used for the subsequent requests. When they are executed, if the provided token is invalid or expired, we will receive a 401 UNAUTHORIZED status code from the server. Otherwise, the request will be successful. The authentication mechanisms that we mentioned earlier follow the basic authentication model, which is preferred for web applications. However, when you're writing APIs, you will need other approaches, in order to deal with security based on the use of tokens (such as JWT). If you are not writing APIs, your application can be secured using the JSON Web Tokens RFC (https://tools.ietf.org/html/rfc7519).

Today, this is the most common method for authenticating mobile applications, modern single-page applications (SPA), and REST APIs.

Let's review some standards created around authentication mechanisms using tokens:

• OAuth (Open Authorization): This is an open standard for authentication and authorization based on tokens that enable the use of a third-party actor to delegate the authentication process. You should only use this standard when you have three parties: yourself, your users, and third-party app developers that need your user data.
• OAuth 2: This is a more developed version of the OAuth standard, which allows the user to grant limited access to transfer resources from one application to another, without giving their credentials. You should use this standard whenever you log in to the site using your Google or GitHub account. When doing so, you will be asked whether or not you agree with sharing your email address or account.
• Full request signature: This was popularized by AWS authentication, and was explored in Chapter 9, Serverless Architectures, when we illustrated deploying our functions as services (FaaS) to AWS. We use this concept by sharing a secret between the server and the client. The client signs the completed request using the shared secret, and the server verifies it. For more detailed information, go to http://docs.aws.amazon. com/general/latest/gr/sigv4_si gning.html.