DEV Community

How to Secure the Web: A Comprehensive Guide to Authentication Strategies for Developers

Mahmoud Abbas on April 10, 2023

Introduction As the digital world continues to expand, ensuring the security of web applications and protecting user data has become mor...

Read full post

pilcrowOnPaper • Apr 11 '23

If you're using JWTs, please please please be aware that you cannot revoke existing tokens. This is a major issue if users can change passwords or privileges. In general, sessions will likely be a better choice and most (if not all) major sites use sessions.

Also, using Bearer tokens as stated here:

When the user makes a request to the server, the token is included in the request in the Authorization header prefixed with the word "Bearer ", then the server verifies the token and grants access to the application if the token is valid.

isn't possible if you're storing it with http-only cookies.

if you are willing to go the extra mile, you can use a refresh token and an access token. which is the way I prefer to do it.

Using 2 types of tokens won't make your application more secure if you're storing both of them inside cookies. An attacker will likely have access to the refresh token if they can steal the access token.

Every auth strategy will be susceptible to CSRF and/or XSS since you're storing something onto to browser. Setting same-site to strict means your users won't be logged in if they access your website via a link. This isn't an issue for websites for say banks, but will likely make UX worse for most sites. Check the Origin header for CSRF protection or use traditional CSRF tokens instead.

FJones • Apr 13 '23 • Edited

Using 2 types of tokens won't make your application more secure if you're storing both of them inside cookies. An attacker will likely have access to the refresh token if they can steal the access token.

Yes, this is true. However, refresh tokens are supposed to be used with short-lived authorization tokens and (importantly) invalidated when reused. This limits the attack potential to at worst two authorization tokens' lifetimes - the originally-hijacked one, and the one fetched with the refresh token, until the real user tries to redeem the refresh token (at which they must be required to re-authenticate, and none of the refresh tokens issued up to this point must be valid anymore).

Obviously this all matters very little if the attack vector is persistent, and authorization tokens should indeed be used as Bearer tokens rather than cookies, but refresh tokens do serve a security purpose.

Nosh Ghazanfar • Apr 13 '23

Totally agree with you. That is why I have clearly stated those things in the article itself here: dev.to/nosherwan/effective-securit...

Mahmoud Abbas • Apr 13 '23

Thanks for sharing this.

Will look more into it and update the article accordingly.

Mahmoud Abbas • Apr 11 '23

These are some good points. thanks for sharing them.

You gotta admit that every one of these approaches has a downside.

cubiclesocial • Apr 14 '23

There's one authentication type you missed: WebAuthn.

In my experience, SAML is a nightmare. When it works, it's a solid SSO solution for the end-user. When it doesn't work, it can take several hours of staring at the configuration on the enterprise side to spot the one thing that was overlooked. In an enterprise setting, there's at least one major SAML related problem every day for some random user. There's no particularly good enterprise alternative to SAML though as it is baked into ADFS, which makes it the de facto standard.