Most of the web applications use some kind of authorization and authentication subsystems to allow its users to access private information of the application. However, the authentication process can be tricky if you don't have a clear idea about how to implement it as Backbone does not provide a hint about how to do it.
Backbone is authentication agnostic, which means that its does not provide objects or tools to implement an authentication strategy. The advantage is that Backbone is not coupled with an authentication mechanism and the disadvantage is that you should care about it.
As Backbone was made with REST APIs in mind, you will have to deal with the authentication mechanisms that are common in that kind of APIs. That's a good reason why Backbone does not impose or provide tools in order to authenticate users.
Another thing to keep in mind is that REST APIs should be stateless, which means that they do not keep track of the requests that you previously made. What it means for you is that if you make a login request, you will expect the server to recognize you on the subsequent requests; however, in a stateless server, it will not remember you.
This may sound crazy if you have not worked with REST web services before; however, you have to authenticate each time you make a requests to the server. That's necessary and there are many available ways to do it; you should consult the API documentation in order to know the exact details of the authentication algorithm.
Despite the many options that are available, they are very similar each other with changes in just some kind of details; however, in essence, they work in a very similar way. Therefore, don't worry about the number of different ways that are available to authenticate; learn the basics and change the details.
Authenticate against a stateless API implies that you should authenticate each time that you make a request to the server; keep in mind that a stateless server does not keep track of the previous requests. This means that each time you make a request to the server, it will process the petition as the first one.
As sessions are not stored in the server, you should put that information somewhere else. For Backbone applications, the right place to store the session data is the browser, you can use localStorage to store and retrieve the session data and JavaScript to manage the session.
The simplest way to authenticate against a RESTFul API is with the HTTP Basic Authentication. The idea behind this is simple; you should include an encoded version of your username and password for every request you make. It may sound risky to send your user and password for each request, and it is. For this reason, it's highly advisable to only use Basic authentication where you have the HTTPS connections enabled:
Figure 10.1 Basic authentication schema
The user and password should be sent under the Authentication header of the request. Consider the following scenario:
- User: myuser
- Password: 123456
To encode the Authentication header, the user and password should be concatenated with the : character as the separator.
myuser:123456
Then, the string should be encoded as base64, as follows:
$ echo myuser:123456 | base64 bXl1c2VyOjEyMzQ1Ngo=
The resulting string should be used for every request made to the server:
GET /api/contacts Authorization: Basic bXl1c2VyOjEyMzQ1Ngo=
The server will decode and authenticate you for each request you make. Remember that you should not use this mechanism without HTTPS. It's very easy for someone to intercept a request header and decode the string in order to discover your user and password.
The OAuth2 protocol was made to share resources among services without the use of a user and password. It is possible that you have used an application where you can authenticate using a social network account. That's OAuth2 in action. The OAuth2 authentication is an authorization framework described in RFC 6749, as follows:
Figure 10.2 OAuth2 abstract flow
In the preceding figure, you can see an abstract diagram of authentication using the OAuth2 algorithm. You can identify the next entities, as shown in the following:
- A Resource Owner is the entity that owns the protected data. This is normally a person.
- The Web application is the application that wants to access the private data of the Resource Owner.
- An Authorization server identifies and authenticates the users of the Resource server, where the protected data lives.
- An Access token is the data to be used in the Resource server in order to authorize the resource access. The Access tokens normally have an expiration time.
- The Resource server is the host that serves the protected data.
Note that the Resource server and the Authorization server can be the same host. The authentication process is as follows:
- The application asks for authorization to the resource owner.
- The resource owner authorizes and an authorization key is issued.
- The application uses the authorization key to exchange it for an access token.
- The authorization server validates the authorization key and the applications.
- The authorization server issues an access token and returns it to the application.
- The application can use the access token to access the protected resources.
The issued access token should normally expire from time to time in order to prevent an attacker from using it maliciously. When a token expires, the application should repeat the authentication process.
However, it's not practical to log in each time that a token expires. In order to prevent this, the authorization server issues another token named refresh token that can be used to issue a new access token when the current access token expires.
When you want to access the private data of a service such as Facebook, Twitter, Google, and so on, you must register your application with the service first. When you register your application with the service, they will ask you for an application name, description, website, and so on.
When the application is registered, the service will give you some tokens to identify your application, these tokens include two key data, as follows:
If the REST server that you are building for your application is accessed only by you, you can manually generate a ClientID and ClientSecret as constant values in the application.
If your REST server will expose a public API for anyone who wants to play with the application data, you should develop some kind of application registration (such as user signup) in order to allow others to register their applications.
In the previous section, you have seen the OAuth2 protocol as an abstract schema of authentication. The RFC 6749 document specification describes four different ways to obtain an access token.
Authorization code grant is the most complete authorization flow; its main usage is to access private resources of the user from another server:
Figure 10.3 Authorization code grant
Refer to preceding figure. Server App is an application server (such as Node.js, Python, and so on), and the API Server is a third-party server, where the private resources lives (such as Facebook, Google, and so on).
In the Authorization Code Grant scenario, the Server App wants to access the data from the API Server in benefit of the User. This is done through the Server App; as the user interacts with Backbone App, it makes requests to the Server App, then Server App can fetch the data from the API Server, apply some processing, and return a response to the Backbone App.
The Backbone App never establishes a single connection to the API Server, it is the responsibility of Server App so that Backbone App only sees a single Server App.
This is a simplification of Authorization Code Grant; the usage of implicit grant is for pure frontend applications without server or mobile applications:
Figure 10.4 Implicit grant
In the implicit grant, App Server does not exist, therefore, the Backbone App should communicate directly with the API Server. Despite the simplicity of the implicit grant, you should be warned about the security issues.
To minimize this risk, your applications should be secured with HTTPS and do not use this flow type if you don't have it enabled. Another related issue is that this grant type does not issue a refresh token, which means that you should re-login when the access token expires.
This grant type is useful when the Backbone App and API Server are the same application. In other words, the frontend application and the backend server are developed by you, which means that you are not accessing to third-party resources.
As your application owns all the resources, you will need the user and password of the application to authenticate it:
Figure 10.5 Resource owner password
The preceding diagram is very similar to the Implicit Grant diagram; however, in this case, you don't need to use ClientID and ClientSecret tokens, which simplifies the authentication process.
When you use this grant type, it feels like the classic way of authentication; you should send your user and password to the server and it will then tell you whether your credentials are valid or not. If they are valid, you will receive a valid access token that you can store and use as you want.
Client credentials grant is used when you have a trusted client that accesses the server resources. A business partner, for example. In this grant type, you are not authenticating an user but an application, therefore, you don't need an user or password.
In this grant, you should use ClientID and ClientSecret, if the API Server trusts the client, an access token will be issued.
Figure 10.6 Client credentials
In the previous sections, you have seen how to use the OAuth2 framework to authenticate against a REST server; in the OAuth2, specifications are described in four ways to make authentication and the use of any one of them depends on the requirements of the application.
However, the goal of the all these grant types is to get an access token that can be used for the next server request. Once you have an access token, the interaction with the API server should be transparent for Backbone App, the token should be send without the knowledge of rest of the application.