This content originally appeared on DEV Community 👩💻👨💻 and was authored by shrey vijayvargiya
I treat my application server as a club party to develop the perfect authentication flow in just 13 steps
Under the Hood
To all developers, understanding backend and creating servers via Node frameworks or Python having authentication flow is a must. But our servers more often tend to decline the security threats. Authentication flow is not for logged-in users or authenticated users but for securing your servers and database from foreign unauthorised requests.
Unauthorised request or any attacks like injections, broken authentication leads to malware attacks and unnecessary changes in our database. Ultimately leading to affecting the data of our authorised and trusted users.
What is an Authentication Flow?
This is the most common question and searched google topic when comes to creating servers. We often tend to fall for 3/4 things while adding authentication to our servers. Some of them are as follows —
- Add authentication login or sign up for users**
- Create every API that is secured or protected routes that can only be accessed once users are logged in.
- In case of Malware attacks or any forceful penetration to protected routes shut down the servers and thrown out that strange user.
There is as such no loophole within this approach, the overview is the same but what comes to un-secure and shielded authentication is execution and authentication flow behind it.
So authentication flow explains the complete flow or way around to access your servers and application database. How will one access your services is explained easily by an authentication flow.
Overview of how our authentication for club party should work
Assuming the application is just an e-commerce application and every user has its profile with some sensitive information being shared. Your approach while creating a secured server should in detail work as explained-
- User should be logged in via login to enter within the party
- For new users, a door called signup is the only way to enter the party.
- Both the processes either signup or login required at least a valid and unique email ID and a password by the user entering the party.
- Email ID and password schemas will be checked on the gate itself before allowing the user to enter.
- In case of an invalid email or password, the user will be asked to implement the necessary changes otherwise he will not be allowed.
- Once credentials provided by the user were correct and valid and approved user is handover with the token at the gate itself.
- Every token accorded to the user is unique and created by the servers themselves.
- Since the servers are the one who creates the token so they only can decode the token.
- Once the token is hand over to the corresponding user, the user has to carry this token while enjoying the club party.
- Inside the club party, we do have other activities too like drinks, games which can be treated as buy now doors. A user who is willing to make a play game or have a drink should pass the Buy now or Payment door.
- This Buy Now door or Payment door also has a doorkeeper or bodyguard. The single and yet most important work of this bodyguard is to check the token validity which the particular user in the queue will provide. Once the token provided by the user is valid he/she will be allowed to pass the Buy now door and hence purchasing transaction is over.
- This process repeats with almost every door, the doors that need to secure because they directly relate to the database. Some doors within the club party are not too sensitive like access to a swimming pool, in that case, a user doesn't need to validate the token.
The speciality of this party token
This single token hand over to the user while entering the application is created by the servers itself and chance can be decoded by the servers only.
Every token is unique and is only valid for a few hours or days or weeks. This means the user once have the token can only access the application for a certain amount of time. The threshold is set by the servers only, some servers allowed users to use the token for 14 days or even 30 days whereas some servers like MongoDB allowed the users to use the token for one time only.
How this token is created and decoded
This is the part where the complete security of your application can either be compromised or unprecedentedly secured. The idea behind the token is -
- Create a random string, for example, a hash string.
- The string should be unique to every user.
- Set the threshold time to the validity of this string
- After the threshold time is crossed the string either gets delete automatically or shows some invalidity sign.
There are multiple ways to generate protected token for servers. JWT, OAuth, Passport tokens but most of them works in the same way.
The secret behind the most secured token
The best way to create the most secured token is the way it decoded by the servers. For example, when the user tries to log in or sign up, create a token using his/her email id because the email id will be the unique thing. Once the token is created using an email id we just have to depart the token and get the matched email id present in the token at the door of the application.
If the email id present within the token is the same as the email id in the body of the request then the token is coming from the correct user. Followed by another layer of security where we will decode the token from the algorithm used by our servers only.
Way to create a perfect token
I loved the JSON web token, the best part of JWT is that he allowed you to add some user data within the token itself which can be re-checked and validate once the user comes back and send the token for validity.
Secure Authentication via JSON Web Tokens (JWT)
JWT is easy to integrate and powerful and secured so always the first preference to access.
Summary
Party doors are open to all whosoever will provide perfect and honest credentials like Email and password.
A door bodyguard at the gate will check the credentials provided by the customers.
Once the credentials are correct, the bodyguard will give every customer the token and allow them to enter the club party.
There are other doors too within the club party, for example, drinks, games and so but those can only be accessed once the token is valid and provided by the customer.
Again every other door will have its own bodyguard who will cross the check the token provided to the user from the database.
Once the token cross-checked is done the customer can enjoy his/her drinks or games.
Conclusion
I hope you enjoy the club party, until next time. Have a good day, people. And do not forget the follow me😁.
Keep developing
Shrey
iHateReading
This content originally appeared on DEV Community 👩💻👨💻 and was authored by shrey vijayvargiya
shrey vijayvargiya | Sciencx (2022-10-17T11:59:23+00:00) 13 steps for perfect Authentication Flow in Backend. Retrieved from https://www.scien.cx/2022/10/17/13-steps-for-perfect-authentication-flow-in-backend/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.