Authorization

Authorization은 사용자가 Spotify 데이터와 기능에 접근할 수 있는 권한을 부여하는 과정을 의미합니다 (예: 애플리케이션이 사용자의 플레이리스트에 접근하려면 사용자의 허가가 필요함).

Spotify는 OAuth 2.0 인증 프레임워크를 구현합니다:

인증 개요

여기서:

• End User는 Spotify 사용자를 의미합니다. End User는 보호된 리소스(예: 플레이리스트, 개인 정보 등)에 대한 접근 권한을 부여합니다.
• My App은 보호된 리소스에 대한 접근을 요청하는 클라이언트입니다(예: 모바일 또는 웹 애플리케이션).
• Server는 보호된 리소스를 호스팅하고, OAuth 2.0을 통해 인증 및 권한 부여를 제공합니다.

보호된 리소스에 대한 접근은 하나 이상의 스코프에 의해 결정됩니다. 스코프는 애플리케이션이 사용자 대신 특정 기능(예: 플레이리스트 읽기, 라이브러리 수정 또는 스트리밍)을 사용할 수 있도록 허용합니다. 권한 부여 중 설정한 스코프에 따라 사용자가 부여하는 접근 권한이 결정됩니다. 스코프에 대한 자세한 정보는 스코프 문서에서 확인할 수 있습니다.

권한 부여 과정에서는 유효한 클라이언트 자격 증명이 필요합니다: 클라이언트 ID와 클라이언트 비밀. 앱 가이드를 따라 이들을 생성하는 방법을 배울 수 있습니다.

권한이 부여되면, 권한 부여 서버는 액세스 토큰을 발급하며, 이를 사용하여 사용자 또는 애플리케이션 대신 API 호출을 할 수 있습니다.

OAuth2 표준은 액세스 토큰을 요청하고 받을 수 있는 네 가지 grant types(또는 흐름)을 정의합니다. Spotify는 다음 흐름을 구현합니다:

• Authorization code
• Authorization code with PKCE extension
• Client credentials
• Implicit grant

어떤 OAuth 흐름을 사용해야 하나요?

어떤 흐름을 사용할지 결정하는 것은 개발 중인 애플리케이션에 따라 다릅니다:

• 사용자가 한 번만 권한을 부여하고, 클라이언트 비밀을 안전하게 저장할 수 있는 장기 실행 애플리케이션(예: 서버에서 실행되는 웹 애플리케이션)을 개발 중이라면, Authorization code flow를 사용하는 것이 권장됩니다.

• 클라이언트 비밀을 안전하게 저장할 수 없는 상황(예: 데스크톱, 모바일 애플리케이션 또는 브라우저에서 실행되는 JavaScript 웹 애플리케이션)에서는 Authorization code with PKCE를 사용할 수 있습니다. 이 방식은 권한 부여 코드가 가로채지는 것을 방지할 수 있습니다.

• CLI 또는 데몬과 같이 백엔드에서 실행되는 일부 애플리케이션의 경우, 시스템이 사용자 대신 애플리케이션을 인증 및 권한 부여합니다. 이러한 시나리오에서는 Client credentials flow가 일반적으로 사용됩니다. 이 흐름은 사용자 인증을 포함하지 않으므로, 사용자 정보가 필요 없는 엔드포인트(예: 사용자 프로필 데이터)를 액세스할 수 있습니다.

• Implicit grant는 몇 가지 중요한 단점이 있습니다: 토큰이 신뢰할 수 있는 채널이 아닌 URL로 반환되며, 리프레시 토큰을 지원하지 않습니다. 따라서 이 흐름은 사용을 권장하지 않습니다.

다음 표는 각 흐름의 동작을 요약한 것입니다:

흐름	사용자 리소스에 액세스	비밀 키(서버 측) 필요	액세스 토큰 갱신
Authorization code	예	예	예
Authorization code with PKCE	예	아니요	예
Client credentials	아니요	예	아니요
Implicit grant	예	아니요	아니요