Building robust authentication systems has become increasingly complex as applications grow. Just last month, I struggled to reconcile multiple authentication methods in a client project. Traditional approaches often fall short when scaling across platforms. How can we securely manage diverse authentication strategies without compromising user experience? Let’s explore a comprehensive solution using Passport.js.
First, we initialize our Express project. I prefer TypeScript for type safety, especially with authentication flows. Our dependencies cover essential authentication packages and security modules:
npm install express passport passport-local passport-google-oauth20 passport-github2 passport-jwt jsonwebtoken bcrypt
npm install --save-dev @types/passport @types/express typescript ts-nodeDatabase design is crucial. Here’s a condensed Prisma schema highlighting key relationships:
model User {
id String @id @default(cuid())
email String @unique
oauthAccounts OAuthAccount[]
localAuth LocalAuth?
roles UserRole[]
}
model OAuthAccount {
provider String // 'google','github','discord'
providerId String
userId String
@@unique([provider, providerId])
}
model LocalAuth {
passwordHash String
userId String @unique
}
model UserRole {
userId String
role Role @relation(fields: [roleId], references: [id])
}
model Role {
name String @unique
permissions String[] // ['read:data','write:content']
}Now let’s configure our core authentication setup. Notice how we initialize multiple strategies simultaneously:
import passport from 'passport';
import { Strategy as GoogleStrategy } from 'passport-google-oauth20';
import { Strategy as JwtStrategy } from 'passport-jwt';
passport.use(new GoogleStrategy({
clientID: process.env.GOOGLE_CLIENT_ID,
clientSecret: process.env.GOOGLE_SECRET,
callbackURL: '/auth/google/callback'
}, async (accessToken, refreshToken, profile, done) => {
const user = await findOrCreateUser({
provider: 'google',
providerId: profile.id,
email: profile.emails[0].value
});
return done(null, user);
}));
passport.use(new JwtStrategy({
jwtFromRequest: (req) => req.cookies.access_token,
secretOrKey: process.env.JWT_SECRET
}, (payload, done) => {
return done(null, payload.user);
}));For JWT management, we implement refresh token rotation - a critical security practice:
const generateTokens = (user) => {
const accessToken = jwt.sign(
{ user: { id: user.id } },
process.env.JWT_SECRET,
{ expiresIn: '15m' }
);
const refreshToken = crypto.randomBytes(40).toString('hex');
await storeRefreshToken(user.id, refreshToken); // Store in Redis
return { accessToken, refreshToken };
};
app.post('/refresh-token', async (req, res) => {
const oldRefreshToken = req.cookies.refresh_token;
if (!oldRefreshToken) return res.sendStatus(401);
const userId = await verifyRefreshToken(oldRefreshToken);
if (!userId) return res.sendStatus(403);
// Delete old token immediately after verification
await revokeRefreshToken(oldRefreshToken);
// Generate new tokens
const { accessToken, refreshToken } = generateTokens(userId);
res.cookie('access_token', accessToken, { httpOnly: true });
res.cookie('refresh_token', refreshToken, { httpOnly: true });
res.sendStatus(200);
});Role-based access control integrates seamlessly through middleware:
const rbac = (requiredPermission) => {
return async (req, res, next) => {
const userRoles = await getUserRoles(req.user.id);
const hasPermission = userRoles.some(role =>
role.permissions.includes(requiredPermission)
);
if (!hasPermission) {
return res.status(403).json({ error: 'Forbidden' });
}
next();
};
};
// Usage in routes
app.get('/admin/dashboard',
passport.authenticate('jwt', { session: false }),
rbac('admin:dashboard'),
(req, res) => { /* secure content */ }
);Security considerations shouldn’t be an afterthought. I always implement these measures:
app.use(helmet()); // Security headers
app.use(rateLimit({ // Brute-force protection
windowMs: 15 * 60 * 1000,
max: 100
}));
app.use(cors({ // Strict CORS policy
origin: process.env.CLIENT_URL,
credentials: true
}));Testing authentication flows requires simulating real-world scenarios. Here’s how I verify OAuth callbacks:
describe('Google OAuth Flow', () => {
it('should create new user on first login', async () => {
const mockProfile = {
id: 'google-123',
emails: [{ value: 'test@google.com' }]
};
const user = await simulateOAuthCallback('google', mockProfile);
expect(user.email).toBe('test@google.com');
expect(user.oauthAccounts[0].providerId).toBe('google-123');
});
});Common pitfalls? Token management tops the list. Always store refresh tokens securely (never in local storage), rotate them frequently, and implement immediate revocation. Another frequent oversight: properly handling multiple authentication methods per user. How might you merge accounts when users sign in through different providers?
Frontend integration follows consistent patterns. For OAuth, redirect directly to the provider. For JWT, store tokens in HTTP-only cookies and include credentials in requests:
// React example
const loginWithGoogle = () => {
window.location.href = 'http://api.domain.com/auth/google';
};
// Axios interceptor for token refresh
api.interceptors.response.use(null, async (error) => {
if (error.response.status === 401) {
await refreshTokens();
return api.request(error.config);
}
return Promise.reject(error);
});This architecture supports scaling across platforms while maintaining security. Mobile apps consume the same JWT endpoints, and server-side rendering works with session cookies. What edge cases might emerge when adding new authentication providers?
I’ve implemented this pattern in production with excellent results. Users appreciate seamless sign-ins across devices, while the system maintains rigorous security standards. The hybrid approach eliminates session store bottlenecks and simplifies permission management.
Found this useful? Share your implementation experiences below! What authentication challenges are you facing in your current projects? Let’s continue the conversation - like and share if this helped you approach authentication differently.
