There are many different ways to implement authentication in an application. In this video, you’ll learn about server-based authentication, token-based authentication, and the advantages of using federation for user authentication.
<< Previous Video: PAP, CHAP, and MS-CHAP Next: Access Control Models >>
Authenticating to a web server can be somewhat of a challenge. That’s because web communication is what we call a stateless communication. The command or request that you’re sending to the web server has no relationship to the previous command that you may have sent. So then how do you provide authentication with the first request to the web server, and then continue to allow that authentication with continuous requests even though this communication is stateless?
Traditionally we have accomplished this using a server based authentication, where the server keeps track of exactly who’s logged in. Usually this is done by assigning a session ID to an individual user when the login process occurs. And each time a request is sent, the server checks to see if that session is still valid.
As you can imagine, on a very busy web server, this can add a significant amount of overhead. This makes it very difficult to scale as you add users. It also becomes more difficult as you add more redundancy and provide more access across the cloud. If you have someone who’s also accessing the services on their desktop, on their mobile device, and on their tablet, it becomes much more difficult to manage all of these different session IDs.
For the server based authentication, when the client begins the login process, a separate piece of session information is kept and maintained on the server. Additional application requests will check the session information for each application request. And if the session information matches, the response is sent from the server.
A more scalable form of authentication is a token based authentication. When you use token authentication, the server is not keeping track of any session information, but instead is using a stateless form of authentication. When token based authentication is used, the client will authenticate normally, but instead of storing session information on the server, the server will send the client a token and the client will store that token locally. Each time a subsequent request is made to the server, the client includes the token along with the request. The server simply validates the token, examines the request, and then we’ll send the response back to the client.
Here’s the token based authentication process. The client logs in normally to the server. The server processes the authentication, and if it’s valid it sends a token back to the client that the client stores locally. During the application request, the client will send the request along with the token. The server will validate the token and then send the response to the application. This maintains the stateless capability of HTTP. It’s now very scalable, because the session information is being stored on the client. And it’s secure, because the server can have that token expire after a certain amount of time.
This also means that the authentication process can be completely separate from the application itself. You can even have the tokens provided by a third party, and have the local server accept those tokens as a form of authentication.
We commonly see this type of token based authentication used with federation. That’s when we’re providing access to others who may not necessarily have a local login on our systems. Third parties can then create a federated network so that users can log in with separate credentials that are located elsewhere. You’ve probably seen login screens that allow you to log into a third party using Twitter credentials, Facebook credentials, and other third party logins. These third parties must set up this trust relationship in advance, but once it’s in place users can use whatever method of authentication works best for them.
One open method for authentication and authorization is SAML– that’s the Security Assertion Markup Language– where you can authenticate through a third party to provide access to local resources. A good example of this is Shibboleth, which is an open source software that implements SAML to be able to have this single sign on capability. Unfortunately, SAML was never designed for mobile applications, and so you don’t often see SAML being used in our modern mobile networks.
OAuth is a protocol that provides resource authorisation. It was created by Twitter, Google, and other very large technology companies. It usually is combined with OpenID Connect which handles the single sign on, and then OAuth determines what type of resources should a person have access to. You often see OAuth used with Twitter, Google, Facebook, and many other organizations.