Securing and defining how you’ll allow users to access your application(s) is a simple, yet complicated decision to make. Not only is this the first true barrier to entry for your end users, but it also is a key defining point for the overall usability of your application. So making the right choice matters. To assist you with that, I’ll provide some of the questions I use to make that determination.
Third-Party Platform Vs. Custom Build
Before any additional thought, or work for that matter as well, the decision between a third-party provider and building in-house must be addressed. Each choice has situations where it becomes a no-brainer to choose one over the other. For third-party, if you’re needing to iterate fast then nothing beats integrating with a solution that is out of the box stable, and secure. However, in situations where there are strict security rules and procedures around user data(i.e. Enterprise), then a custom-built solution is the only feasible choice.
When you’re in between those two extremes, that’s where things get tricky. That’s where you need to look at a few key factors: the type of product you’re building, what security concerns you’ll need to address, the target customer base, engineering department size, and needed velocity.
Storing Sensitive Data
Initially, storing sensitive data appears to be more related to data architecture decisions. Which is a key component of that architecture in your build. However, to properly support a session, a user authentication token(JWT for example) has to be stored somewhere. So with that, here we are!
In storing sensitive data, we have to think critically about what makes the most sense. While at the same time, we always get put into two camps: localStorage and cookies. While neither is 100% secure, both have advantages. In turn, that makes the choosing process a bit easier.
For localStorage, this makes sense if you don’t need your token to expire. With cookies, overall the best choice and most widely used, and are great at easily dynamically handling expiration and ensuring that your cookie can only be handled by the backend(if needed). Also for additional security here, it’s always great to encrypt your authentication token when being stored and transferred.
Authentication Check Frequency
Another aspect of authentication, closely tied to the storage method, that must be established is the frequency with which your authentication token must be refreshed. Every industry has different security practices that must be followed to ensure compliance and the most possible protection for end-users.
Setting up refreshing can be as simple as generating a new token every API call, bit excessive but can be needed for some industries, or setting up an interval where an API call is made to refresh your auth token.
In Closing
Authentication strategies are fluid, and based on the type of application you’ll be building. Never keep things static with your approach, and become familiar with the multitude of stable approaches that can be applied universally. Either by themselves or in some form of a conjunction of multiple together.
Happy coding and authenticating!