Authentication vs authorisation - what's the difference?
In the film "Mission Impossible", Ethan Hunt, an IMF agent infiltrates a secret facility by duplicating someone's face, iris, and even fingerprints. But can you tell whether he entered the facility through authentication or authorisation?
When it comes to cyber security these are two terms which play a crucial role in providing security and access. However, these two concepts often get conflated and confused. To this extent let’s break these two terms down to demystify and clearly highlight the key differences.
Authentication - are you who you say you are?
In short, authentication is a process of determining that somebody really is who they claim to be. Let’s start with a real-world example. An employee enters an ID code into a keypad and the building security system, then scans their face. The building security then takes that ID code and makes sure that ID code belongs to an employee of a that building. It also takes the face scan and compares it to what it has on file to verify they are who they say they are. If the security system is happy, it issues them a pass and on that pass is encoded a set of information about the employee and the roles that they have within the company. This is great real-world example of authentication. The employee has issued their credentials to the building, and it’s given them a pass and allowed them access.
The process of authentication in a web application is very similar. The user will normally give a set of credentials such as a username and password to the system, the system will check to see if that user exists, and then make sure the password matches that stored in the database. If it does and everything checks out, the application will then issue what’s known as a ‘token’. This token normally has encoded on it a representation of who the user is and what their role is within the application. Typically, this only happens once per session. In addition, the access token normally has an expiry time meaning the user only has to authenticate perhaps once per day.
In relation to APIs, authentication is an important way of keeping an API secure as it denies access to anonymous users so you know who is accessing your system and to a certain extent you can control what resources a user sees based on who they are. However, what you also really need is a way of preventing authenticated users from accessing resources that you do not want them to access. This is where authorisation comes in.
Authorisation – do you have the right permission for access?
Referring to the real-world example above, that same pass issued to the employee of the building might not give them access to all levels within the same building. This is because the building security system has checked their role within the company that’s encoded on their pass and it has determined they are not authorized, or do not have permission, to access certain areas.
Crucially, just because someone has been allowed access into the building does not mean they have been authorized to access all areas. This process again is very similar within a web application. Each time a user tries to access a resource, the application should check to make sure the user is authorized to access that resource. It normally does this by checking the roles encoded on the access token.
A piece of accounting software can provide another good example. An accounting package will have different roles including ‘company owner’ and/or ‘payment administrator’. This would include employees who are allowed to make payments and see the financial information attributed to a particular company. The software package could also include clerical users, data-entry level roles which require them to see only a limited amount of financial information and data. Each one of these roles will encapsulate a very specific set of permissions. For example, a payment administrator role will include permissions such as ‘create payments’ and ‘read payments’. The system will need to check the user’s requesting access has firstly the role ‘payment administrator’ role and the permission ‘create payments’ for someone to create a payment. If they do not, it will deny access even if the user has been authenticated. Authorization should happen each time a user accesses a resource.
Both terms play their part
Going back to “Mission Impossible”, it should now be much clearer how Ethan managed to get into the secret facility. The process of checking whether the biometric information he copied is correct is authentication, and the reason why he could enter the facility is because the cloned user has the authorisation to enter the facility. Simple really, although not an easy entrance!
Authentication is the process of a user presenting some credentials such as a username or password or even biometric data and given access into a system. This usually happens only once per session. Authorisation on the other hand happens every time a user accesses a resource. It determines whether an authentication user has the permission to access a certain resource and if they do not, they are denied access.
Both authentication and authorization are required to deal with sensitive data assets. Without any of them, businesses leave data vulnerable to data breaches and unauthorized access. These two concepts of authentication and authorisation work together to keep your system secure from both external and internal sources. Both these concepts play a crucial role in the security of any business and/or web app design and at times they are not easy to get right and to implement properly. This is why many companies offer services specifically to help with the implementation and development of these important processes.
SSenStone’s OTAC enables one of the most robust and simplest authentication process and we help you set up your organization's per-user or per-device authorizations securely and conveniently with our solution.
