Implementar Authorization Code Flow con Spotify te permite conectar una aplicación web a la API de Spotify usando un backend seguro que intercambia un código por un access token. Esta guía es útil si trabajas con Next.js, OAuth o cualquier servicio que exija un canal seguro para autenticar usuarios.

La lógica detrás de este flujo aplica para casi cualquier proveedor que implemente OAuth 2.0, así que dominarlo con Spotify te abre la puerta a integrar Google, GitHub, Slack y muchos más.

¿Qué necesitas antes de empezar a usar la API de Spotify?

Antes de tocar código, tienes que registrar una aplicación en el portal de desarrolladores. Spotify le llama apps, pero técnicamente en OAuth eso es un client.

Entra a developer.spotify.com, ve al dashboard y autentica con tu cuenta. Crea un nuevo cliente con un nombre descriptivo, por ejemplo auth-code-flow-spotify, acepta los términos y guarda los dos valores que importan: client ID y client secret [01:30].

¿Qué es el client secret y por qué no debo compartirlo? Es la credencial privada de tu aplicación frente al authorization server. Si se filtra, alguien podría suplantar a tu cliente, por eso Spotify permite rotarlo cuando lo necesites.

También debes registrar una redirect URI que coincida con tu aplicación. Si corres el proyecto en local, una ruta válida sería http://localhost:3002/api/callback [02:15].

¿Cómo se guardan las credenciales de forma segura?

Nunca pongas el client ID ni el client secret directamente en el código. Cárgalos como variables de entorno: SPOTIFY_CLIENT_ID, SPOTIFY_CLIENT_SECRET y la URL de redirección también.

Esto es clave porque el intercambio de código por token corre del lado del servidor, y ahí es donde el backend lee esas variables sin exponerlas al navegador.

¿Por qué Next.js encaja tan bien con Authorization Code Flow?

El proyecto del ejemplo es una web app en React con Next.js. Lo importante es que Next ofrece Route APIs, que funcionan como un backend embebido dentro del mismo proyecto [03:10].

Eso resuelve un requisito crítico de este flujo: el intercambio del código por el access token debe pasar por un canal seguro, nunca desde el navegador.

El index del proyecto tiene un único botón de conectar con Spotify que redirige a la ruta /api/login, donde arranca el flujo real.

¿Cómo se construye el authorization request a Spotify?

En OAuth todo es bastante estándar. Los endpoints del authorization server terminan en authorize cuando piden permiso, y en token cuando intercambian credenciales.

Dentro de login.js, que corre del lado del servidor, defines los scopes según los endpoints que vas a consumir [04:30]:

• user-read-private para leer información básica del usuario.
• user-read-email para acceder al correo.
• playlist-read-private para listar playlists privadas.

Luego construyes un query string con los parámetros que el authorization server exige:

• response_type con valor code, porque quieres un código intercambiable.
• client_id leído desde las variables de entorno.
• scope con los permisos unidos por espacios usando join.
• redirect_uri apuntando a tu ruta de callback.

Para serializar todo esto usas el módulo nativo query-string de Node y su método stringify, que arma los parámetros con signos igual y ampersands correctamente [05:40].

¿Qué hace el authorization request? Manda al usuario a Spotify para que vea la pantalla de consentimiento, donde aprueba o rechaza los permisos que tu app solicita.

Al darle clic al botón, verás la pantalla de Spotify pidiéndote permiso con los scopes listados. Cuando aceptas, ocurre el authorization grant: Spotify redirige de vuelta a tu callback con un código en el query.

¿Cómo intercambias el código por un access token?

El archivo callback.js recibe ese código y debe cambiarlo por un access token. Sin esa implementación, Next se queda colgado esperando una respuesta [07:20].

La petición fetch al endpoint token requiere configuración específica:

• Método POST según el estándar.
• Header content-type igual a application/x-www-form-urlencoded.
• Header authorization tipo Basic con las credenciales del cliente.

La autorización Basic se construye codificando en base64 la cadena client_id:client_secret. En el ejemplo se usa una utilidad llamada encode dentro de la carpeta de utilidades del proyecto, que aplica esa codificación de forma sencilla.

En el body de la petición envías otro query string con tres campos: el code que llegó por la URL, el redirect_uri y grant_type igual a authorization_code para indicarle al servidor que quieres canjear ese código por un token [09:00].

¿Cómo entregas el access token al cliente sin exponerlo?

Una vez Spotify devuelve el access token, no lo mandes al navegador como JSON plano. La forma más segura es guardarlo en una cookie httpOnly [10:30].

Esa cookie cumple dos condiciones:

• path en la raíz para que esté disponible en toda la app.
• httpOnly activado para que solo el backend pueda leerla, evitando ataques desde JavaScript del cliente.

Después, en el endpoint del home, parseas la cookie desde los headers usando una utilidad de cookies, extraes el access token y lo devuelves como data al componente. Con ese token en mano, haces fetch al endpoint /me para traer el perfil y luego al de playlists con el ID del usuario.

¿Cuándo conviene usar Authorization Code Flow?

Es el flujo más común que vas a encontrar en servicios que implementan OAuth 2.0. El único requisito real es que tu cliente pueda ejecutar código del lado del servidor, porque el intercambio del código por el token exige un canal seguro.

Si tu aplicación es 100% frontend, sin backend, este flujo no aplica y tendrás que mirar variantes como Authorization Code con PKCE.

El reto: implementa este mismo flujo con un servicio distinto a Spotify. GitHub, Google o Discord son excelentes candidatos para practicar. ¿Qué proveedor vas a integrar tú?