All About Authentication Systems
Authentication is a concept of ensuring that the right people gets access to the information. The age old concept of lock and key has evolved into todays multi-variant authentication systems
Authentication systems are the protective barrier of any software. It makes sure that right people enters the system and access the right information.
Though being the major component of an application, the chances of you building one from the scratch in the industries less, Unless you are working on a project from scratch. That being said, the most common advice in a hackathon is to not waste time implementing login page. Now as years go by and as you grow up the career ladder, it is important to understand how the whole system works to elevate yourself as an architect and make more educated design decisions.
The Common Misconception
When thinking about authentication, the common imagery people have is a login HTML page submitting data to a backend API cross checking it with a data in a DB? Well, though it covers the bare bones of an authentication system. There is more to it which we would discuss in the rest of the blog.
Access Control
Types Of Access Control
Before we move on…
All data sent to clients over public links should be considered “tainted” and all input should be rigorously checked. SSL will not solve problems of authentication nor will it protect data once it has reached the client. Consider all input hostile until proven otherwise and code accordingly.
Basic Authentication
It is the simplest of authentication mechanisms. It is a part of HTTP protocol. It is a challenge response scheme where the server challenges the client to provide necessary information to access the resource
How does it work?
Get the username and password from user
Encode it using
base64
algorithmSet it in the Authorization header and send it along each HTTP Request.
Advantages
Easy and simple to implement
APIs are faster since there is no complex encryption/decryption involved
Disadvantages
Basic Auth implemented in a non-SSL (HTTPS) network is a huge security vulnerability.It is easy to decode an Base64.
Sending passwords over all the HTTP request provides a pool of requests for attackers to pick passwords from. Once they crack one the system becomes open for attacks.
Digest Based Authentication
It is an upgraded version of Basic auth. It overcomes the security vulnerabilities of Basic auth over an HTTP network. We no longer deal with base64
encoded strings, instead the server provides digest for the client to use while encoding the username and password. In digest base auth we no longer have to worry about universally known base64 encoded string.
Note: This doesn’t mean it is ok to send passwords over non-HTTP network, it provides just a safety net if you do so.
How does it work?
Request a server for a resource with no auth
Server sets the header with certain digest information
Get the username and password from user
Hash the username and password along with the digest send it to the server.
Server decodes the string with the digest and allows the user
Advantages
Prevents passwords sent as plain-texts
Avoids Phising
Disadvantages
Digest method is still vulnerable to man in the middle attacks.
Client has to make 2 calls to get a resource, one to get digest information and another to login
Cookie/Session Based Authentication
Cookie/Session based authentication is the most commonly used in web apps. Yes, both session and cookie are not exactly the same but the conceptually either the client uses a cookie/session to identify itself as a logged in.
How does it work?
Get the username and password from user
Set it in request form params and send it to the server
Server validates the user based on the given username and password
Once successful validation, create a cookie and set it in the response
The client then uses this cookie/session to make future requests.
Advantages
We no longer set the password in every request making the window for attacks smaller.
Enables state maintenance in a stateless system. Cookies maintain the state that the user is already logged in.
Can revoke the validity of a cookie anytime.
Disadvantages
Cookie based authentication is suitable only for Single domain system. If you want both a web and a mobile app or may be a separate client server, then you got to deal with CSRF.
Prone to XSS and CSRF attacks since the cookie is available for other apps to read
You need to store the session information in a DB which also brings in the question of scale
Token Based Authentication
Token Based Authentication is a form of stateless authentication. Instead of sending email and password over for authentication we use a server generated token. Oauth, JWT, Open ID all comes under token based authentication
JWT
How does it work?
User submits a username and password
Server validates and returns a singed token JWT
Use the token to allow future requests
Advantages
The server no longer have to bear the overhead of session information
No more CSRF. With token based auth you are dealing with a bunch of APIs consumed by different clients
Works well on microservices architecture.
Disadvantages
Cannot revoke the access to a user.
The safety of the token relies on the consumer of the token.
OAuth2
Oauth2 is an advanced version of Token based authorization. Often we use Facebook/Google/Twitter to sign-in to an application. These are the examples of OAuth2.
How does it work?
User sends an authentication request to say Google/Facebook.
On finding that the user has an account on Google, the Google server responds with an authorization grant.
The requesting application uses the authorization grant access specific information
On gaining the permission, the app generates an access token.
The client then uses the access token to access a resource.
SSO
Personal computers are classic examples of an SSO system i.e., you enter password once and get access to all the apps. Google is another classic example you login to Gmail and get to use all the GDrive apps that comes along with it.
How does it work?
Let’s say you are trying to access Google forms. Google sends a request to the forms, the forms of service inturns calls an authentication service to make sure that the current user is logged in
if the person is already logged in present with the information
If not show him a login screen to authenticate the user.
Oauth Vs SSO
This sounds similar to oauth but, the major difference is Oauth allows only specific access to an app whereas SSO provides complete access of the data available
Advantages
Talk about user experience your user needs to remember only one set of password
Secure, since a single service is holding your password and is responsible for its security
Disadvantages
Single point of failure: When an authentication service goes down all the app relying on it cannot be accessed
Any security breach in the authentication system will open access to a wide set of apps and data.
Two Factor Authentication
Two Factor authentication is a subset of multi-factor authentication. There are 5 broad classification of these factors
Knowledge Factors - Which city are your from?
Possession - OTP, Validation email
Inherent factor - finger print, eye ball scan
Location Factor - GPay
Time Factor - When system is allowed to access only at a specific time
Authorization
Authorization is something that happens once the user logs into the system. Does an user have access to a specific information? For example, in a library the lenders need not know the billing/vendor information related to each book. In a system that involves more than one type of stakeholders, the authorization is as important of authentication.
Access-Control
Authorization is achieved using access control, you can imagine it as a “Restricted Area” sign with a guard.
Types of Access Control
RBAC - Role Based Access Control - A user with specific roles can access specific data. E.g., Only a SuperAdmin can change the Locale of the system.
MAC - Mandatory Access Control - High security systems avail these kinds of access control
DBAC - Discretionary Access Control - The business data decides which information is available for a specific user. E.g., According to the business logic of a library application, only a library lender can only see books lent by themselves.
Which Authentication Method Should You Choose?
Only Web Application - Cookie/Session Based
Expose APIs to user - Token Based
Web + Mobile Apps - Cookie and Token Based
Letting users login easily Oauth
Building apps on top of Google/Facebook - SSO
Authentication In a Distributed System
In a monolithic application the authentication APIs are tightly coupled to the app itself I.e., we will have a single DB storing both the user information and the business data. In that case there is a single instance of a server responsible for authentication.
In a distributed system with microservices architecture the design becomes a bit more complicated.
Answering the following questions and understanding its pros and cons will help us land in an educated decision
Authentication inside every microservice
Microservices architecture directly translates to independent services working together with that ideology in mind “Auth inside every microservice” looks like an anti-pattern. Though an advantage of this method is reduced latency, we would end up doing a bunch of redundant things at every server.
Authentication system as a filter
If that’s the case with having auth service at each end and the auth system validates each request like a firewall. The drawback of this method is that auth service itself will become a bottleneck as the number of requests scales up.
Global Authentication
The most commonly practiced method in microservice architecture where the authentication system sets a JWT token to the client and any request that made to the services are then cross verified with the Global system.
Resources
Last updated