My project is a full-stack app with authentication. I used Node.js, Express, and MongoDB on the backend. Users can sign up, log in, and their passwords are safely stored with hashing. I also added GitHub login with OAuth, so people can log in using their GitHub account.
I keep everything secure with JWT tokens and environment variables in a .env file, like my MongoDB URI, secret keys, and GitHub client info. On the frontend, I connect to the backend with fetch requests, and once someone is logged in, they get access to protected routes.
It’s basically a simple version of how real apps like Twitter or LinkedIn handle login systems.
A Cross-Site Request Forgery (CSRF) attack occurs when an attacker tricks a user’s browser into executing an unwanted action on a trusted site where the user is already authenticated. In the context of OAuth, an attacker could craft a malicious authorization request and get a victim to click it. Without safeguards, the authorization server might process the attacker’s request, linking the victim’s account to the attacker’s application.
The state parameter prevents this by acting as a unique session token. The client generates a random value, stores it locally, and includes it in the authorization request. When the authorization server redirects back with a code, it also returns the state. The client checks if the returned value matches the stored one. If it doesn’t, the request is rejected. This mechanism ensures that the response is tied to the original request and blocks CSRF attempts.
Redirect URI validation is one of the most critical parts of OAuth security. A common mistake is validating only the domain or allowing all subpaths. For example:
Imagine the authorization server accepts https://trusted.com/* as a redirect URI. An attacker could register https://trusted.com/evil?capture_code=true. Since the domain is valid, the server redirects the authorization code there. The attacker’s controlled page can then capture the code from the query string and exchange it for an access token.
This leak would give the attacker unauthorized access to the victim’s account. Proper defense requires exact matching of registered redirect URIs (including path and scheme) rather than relying on partial matches or wildcards.
Adding third-party login (e.g., “Login with GitHub” or “Login with Google”) greatly improves user experience: no need to create or remember new credentials, and users gain convenience through single sign-on (SSO). However, this introduces new risks and responsibilities.
One key trade-off is trust and control. By relying on an external provider, the application delegates critical parts of identity management. If OAuth is misconfigured (e.g., improper redirect handling, missing state validation, weak token storage), the app could expose user data even if the external provider itself is secure. Developers must balance convenience for users against the complexity of securing the OAuth flow, carefully testing configurations, validating URIs, and monitoring for potential misuse.