Authentication and Authorization

Authentication and Authorization are 2 independent concepts both of which are constituents of security. Authentication , in a vague manner, means to recognize someone and Authorization depicts to give that person some permissions. To understand it more better, a really simple example would be to know these concepts regarding to operating systems. When we log into our computer the OS checks whether our credentials match to any user of the computer. That is what we call authentication. Once the OS finds a match, it logs us into the computer. Now if we want to open a file then the operating system checks whether we have permission to do so or not. This is the time when the OS is authorizing us. If we have permission then OS will open the file for us otherwise it won't. So in this post we'll see how can we implement these features in any system and take safety measures to prevent intrusions. This post can be a bit boring but its actually a building block of what we'll learn in the future posts and it gives an idea of how things work.

• Authentication
• Authorization
• Server-Client Systems
• Best Practices

Authentication

As we talked earlier, authentication is recognizing the user. If we think about it a bit then we'll notice that authentication should be done before authorization. Its clear that you dont want to check whether a person is allowed to do something before checking if he is even allowed to enter the premises. Authentication can be done in a pretty straight forward manner. User enters his credentials, we check whether we have some registered user with those credentials and allow him in if we found a match. All we need to implement this type of authentication is a user-credentials table where we can search for the user.

Authorization

Authorization deals with the user's permissions. There are some ways how it works.

• User can only see the data what he is allowed to take action on.
• User can see all the data. He tries to take action on arbitrary data and then we check whether he is authorized to do that or not.
• Mixture of above methods. User only see what he is allowed and if he takes action on it then we check again whether he is allowed or not.

Why do we actually need the third way ? The first two ways looks fine but why a double check. The reason for a double check is to prevent intrusions. So if someone actually seeing the allowed data but he uses some hacks to get information of the hidden data then we must ensure that he should not get it. So when a user is allowed to take actions without our provided interface then there must be a double check. In case where the system functions are totally hidden from a user where he is restricted to use only the provided interface then the first method would do fine.

But the second method is actually not supposed to be used in a system where information about the existence of the data is also sensitive. Also it might result in a lot of unauthorized actions and would confuse the user what he is actually allowed to do. So the first or third method to implement authorization would work fine. To implement authorization all we need is access-control table which stores the information about the role and its allowed permissions. The problem increases when we want fine control over a user permission for each data. We'll talk a lot about authorization in the next article and would see how to actually implement it for a server-client based system using an SQL based database and a scripting language like php or python.

Server-Client Systems

Server-Client systems are the systems in which one machine asks for data and other machine serves the data. There can be an API using which a client machine can ask for data and the server machine needs to implement authentication and authorization of the client requests so that it can prevent illegal access to the data. In a server-client system, if the connections are stateless i.e. the server disconnects the client after serving its request then with each request the server will have to authenticate the user first. Also there is a possiblity of exploiting the server without using the given API and thus intruding in the server system. To provide a user-friendly environment, client machines should not ask for user credentials for each and every request, instead they should do it automatically. But doing this on the client machine would require to store the credentials on the machine which ,in the future, can be stolen by any person. So never store the credentials on the client machine. There are 2 protocols which are used in a client-server system.

• Stateless: In this protocol, the server is not required to retain session information or status about each client for the duration of multiple requests.
• Stateful: A protocol which requires keeping of the internal state on the server. So if the connection is made then it is kept alive for multiple requests and the server does not need to do authentication again and again.

Both these protocols have their ups and downs but we are concerned with only authentication here. Most of the application use stateless protocol because it is not exhausting i.e. it does not use resources for only a limited clients. Once a request is served, it is open for other requests. But we are stuck to the problem of repeated authentication in a user-friendly manner. The solution to this problem is that we can generate an access token for each logged in user and then use that token to do the authentication on the server. Normally using only a token cannot prevent what we call "session hijacking" so we'll need to do a lot of more work. In the future posts, we'll see how to actually implement these features in a system.

Best Practices

These practices are actually for developers who have aleary implemented authentication and authoriation in their system. So lets see what we can do to make our system faster and secure.

• Indexing: I hope you all know what indexing means regarding to a database. So always try to use indexing on the field which will be mostly searched. Like if you have user_id, user_name and password fields in your records and you will always want to search for a user using its user_name then apply indexing on that field. It will reduce the database response time.
• Never store sensitive information on client machine.
• Encrypted connections: Use encryption to secure the data you sent over a connection so that even if that data is compromised you'll be safe.
• Understand wrong attempts: If user is providing wrong credentials over and over again then there are chances that a script might be running to tresspass the system. So lock the account in that case, inform the user whose credentials are tried to be used and then unlock the account only when the original user asks.
• Use Captcha: By implementing captcha you are preventing the scripts from attempting false logins.
• Store for lesser duration: If you dont have a "remember me" feature on your login system then store the session data for a shorter duration so that if a client is disconnected for a longer time then he'll have to provide his credentials again. A simple strategy would be to increase the session expire time by some amount, lets say 30 minutes, on every request. So if there is gap more than 30 minutes between two successive requests for the same session then decline that request and ask for the credentials again. This way even if the access token is compromised in the future, data will be safe.

This much for now. In the next article we'll write some code to implement authentication in a client-server system and then we'll see how to implement authorization for different user roles in the system. If you have any suggestion then just drop a comment. You are free to ask anything if you want. Also don't forget to subscribe to get notified about new articles.