You don't need to implement authentication on your own
Clerk, the drop-in authentication and user management solution for React, raised $15 Series A several months ago. If you don't have strong feelings about the funding, look at its user growth curve to get an idea of its current popularity.
If using an external service for all user management is not acceptable to you, there are many other authentication libraries available. The most popular one is NextAuth, as demonstrated by its growing number of stars on GitHub.
The apparent reason for this trend is that they both make a great abstraction for the authentication process. Developers now only need to do some configuration setup, then everything just works in the best way.
Beneath the surface, there is another perspective that advocates for this trend.
You shouldn't implement authentication on your own
TLDR: Itβs all about security.
Developing a secure and robust authentication system requires a deep understanding of security principles, cryptographic protocols, and best practices. Even minor mistakes in the implementation can lead to severe vulnerabilities, putting user data at risk. This is especially true when your system interacts with a third party, as required by third-party authentication (OAuth), which is almost a standard practice for web applications.
By leveraging established authentication libraries or services, developers could benefit from industry best practices while minimizing the risks associated with custom implementations.
You may have a different perspective, especially if you have implemented it yourself. So, let's take a test using OAuth2 to see how well you understand it. π
How and why OAuth2 is designed
I think most people could easily and correctly illustrate the workflow of the OAuth2 as below even with more specific detail:
However, did you know that this well-known workflow is actually one of the four Authorization Grant types of OAuth2, specifically the Authorization Code grant type? It's understandable if you didn't know, as it is the most secure way of doing it. Consequently, the other three options are rarely used in real-life scenarios. Anyway, consider the question below:
Why bother with the code rather than returning the access token directly?
Most people could tell that if so, an attacker could steal the access token by setting the redirect URL to his own server. While itβs true, are you aware that most Auth providers are now providing the ability to set the white list for your direct URL like the below:
If I only allow redirect URLs to our own website, would the problem still exist?
It is if you are not using an encrypted connection (HTTPS). It is possible for Man-in-the-middle attacks to read the access token. You might be asking who still uses HTTP nowadays. However, during the early days having all developers purchase an SSL certificate and properly configure SSL on their domain would be a huge pain and would slow adoption down tremendously. During the early testing phase, this might still be a burden for some developers.
What if using asymmetric encryption to encrypt acess_token so it could only be decrypted using client_secret
It does seem like a possible solution. However, for safety purposes, it may be better to only transmit the intermediary one-time-use "authorization code" that only the intended receiver can exchange (since the client's secret is required). This code would be useless to potential hackers even if they managed to intercept the network transactions since they do not possess the client's secret.
Furthermore, enforcing the backend-to-backend talk between the application server and the authorization server gives more chances to do the security check.
Auth is more than authentication
The above are all talking about Authentication(AuthN), the other part of Auth is Authorization(AuthZ). You can find a more detailed explanation below:
If you have ever implemented a SaaS product, you probably know that authorization (AuthZ) can be much more complicated than authentication (AuthN). Dealing with multi-tenant isolation, soft deletes, group sharing, and mixing role-based access control (RBAC) with attribute-based access control (ABAC) can make it the most complex and error-prone part of your business logic.
To achieve the same level of convenience in authorization as Clerk and NextAuth provide for Authentication, we created the ZenStack: A TypeScript toolkit that supercharges Prisma ORM with a powerful access control layer. You can centralize authorization concerns into the schema using access policies to get the below benefits:
- A smaller code base.
- A more secure and reliable result compared to manually writing authorization logic.
- Better maintainability since when authorization rules evolve, the schema is the only place where you need to make changes.
If you feel interested, you can find an example project in the post below:
ZenStack is our open-source TypeScript toolkit for building high-quality, scalable apps faster, smarter, and happier. It centralizes the data model, access policies, and validation rules in a single declarative schema on top of Prisma, well-suited for AI-enhanced development. Start integrating ZenStack with your existing stack now!
Top comments (3)
OAuth2 is an authorization protocol, not an identity / authentication protocol.
We are making that more clear in the 2.1 draft introduction
ietf.org/archive/id/draft-ietf-oau...
Thanks for the info!
Hello and welcome to DEV. Thanks for sharing the link. Hope you also have a great sharing and learning experience here!