Great question—this is a critical security concern when building OAuth-based login systems, so it’s really smart you’re flagging this early.

Short Answer #

Yes, the risk absolutely exists with your current approach. If you’re accepting Spotify ID and email directly from the client-side (or any untrusted source), an attacker could easily forge these values to create an account pretending to be another user, or even hijack existing accounts.

How to Fix This: Secure Spotify OAuth Implementation #

You need to follow Spotify’s official Authorization Code Flow (the recommended secure flow for server-side applications) to ensure you’re only trusting verified, authenticated user data from Spotify. Here’s a step-by-step breakdown:

1. Redirect Users to Spotify’s Official Authorization Page #

Instead of asking users to provide their Spotify ID/email, initiate the OAuth flow by sending users to Spotify’s authorization endpoint:

• Your frontend links to https://accounts.spotify.com/authorize with required parameters: client_id, response_type=code, redirect_uri, scope (include user-read-email and user-read-private to get necessary user data), and optionally state (a random string to prevent CSRF attacks).
• Users log in to Spotify (if not already) and grant your app permission to access their data.

2. Exchange the Authorization Code for an Access Token (Backend-Only) #

Once Spotify redirects back to your redirect_uri with an authorization code:

• Your backend sends a POST request to https://accounts.spotify.com/api/token with:
  • grant_type=authorization_code
  • code (the authorization code you received)
  • redirect_uri (must match the one used earlier)
  • client_id and client_secret (your app’s credentials—never expose these to the frontend)
• Spotify will respond with an access_token, refresh_token, and token expiration details.

3. Fetch Trusted User Data from Spotify’s API #

Use the access_token to make a GET request to Spotify’s /me endpoint (https://api.spotify.com/v1/me). This endpoint returns verified user information including:

• id (the user’s Spotify ID)
• email (only if you requested the user-read-email scope and the user’s email is verified on Spotify)
• Other profile details like display name

This data is trusted because it’s retrieved directly from Spotify’s API using a valid access token—an attacker can’t forge this response without a valid token tied to the actual user.

4. Create/Link the User Account in Your Database #

Only after receiving and validating the user data from Spotify’s /me endpoint should you:

• Check if a user with this Spotify ID already exists in your database.
• If not, create a new account using the Spotify ID and verified email from the API response.
• If they do exist, link the session to their existing account (for login).

5. Additional Security Hardening #

• Validate the Access Token: Spotify’s access tokens are JWTs. You can verify their signature using Spotify’s public keys to ensure they haven’t been tampered with. Even with this, always call the /me endpoint to confirm the token is still valid and tied to the user.
• Use PKCE for SPA/Mobile Apps: If you’re building a single-page app or mobile app (where you can’t safely store a client_secret), use the Authorization Code Flow with PKCE to prevent authorization code interception.
• Use Spotify ID as a Unique Identifier: Store the Spotify ID as a unique, non-editable field in your database to ensure each Spotify user can only have one account.
• Handle Token Refresh: Use the refresh_token to get new access tokens when the old one expires, so users don’t have to re-authorize constantly.

Why This Works #

By relying on Spotify’s OAuth flow and fetching user data directly from their API via your backend, you eliminate the risk of forged user IDs/emails. All user identity data comes from a trusted source, and the access token ensures that only users who’ve successfully authenticated with Spotify can have their accounts created or accessed.

内容的提问来源于stack exchange，提问作者Jason