next-auth icon indicating copy to clipboard operation
next-auth copied to clipboard

Enhance Spotify provider to support custom scopes via authorization params

Open sshuvoo opened this issue 1 year ago • 1 comments

Provider type

Spotify

Environment

## System:
    - OS: Windows 11 10.0.22631
    - CPU: (6) x64 Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz
    - Memory: 1.19 GB / 7.88 GB
## Binaries:
    - Node: 20.12.0 - C:\Program Files\nodejs\node.EXE
    - npm: 10.8.2 - C:\Program Files\nodejs\npm.CMD
## Browsers:
    - Edge: Chromium (127.0.2651.74)
    - Internet Explorer: 11.0.22621.3527
## npmPackages:
    - next: 14.2.5 => 14.2.5
    - next-auth: ^5.0.0-beta.20 => 5.0.0-beta.20
    - react: ^18 => 18.3.1

Reproduction URL

https://github.com/sshuvoo/next-auth-example

Describe the issue

The Spotify provider in Auth.js doesn't support setting custom scopes through the authorization.params.scope option, unlike other providers. This inconsistency makes it difficult to configure custom scopes for Spotify in the same way as other OAuth providers.

Currently, the Spotify provider has a hardcoded scope in its authorization URL:

{authorization:
  "https://accounts.spotify.com/authorize?scope=user-read-email",}

This means that users can't easily customize the scopes without overriding the entire authorization URL. I've tried to use the standard configuration method used for other providers:

providers: [
   Spotify({
      authorization: {
         params: {
            scope: 'user-top-read user-read-email',
         },
      },
   }),
]

However, this doesn't work as expected, and the default "user-read-email" scope is still used.

Current workaround (After analyzing source code (Spotify.ts)):

Spotify({
   authorization: `https://accounts.spotify.com/authorize?scope=${encodeURIComponent('custom scopes here')}`,
})

How to reproduce

Set up a new Auth.js project with the Spotify provider. Try to configure custom scopes using the standard method:

export const { handlers, auth } = NextAuth({
   providers: [
      Spotify({
         authorization: {
            params: {
               scope: 'user-top-read user-read-email',
            },
         },
      }),
   ],
})

Initiate the Spotify authentication flow. Observe that the authorization URL still only includes the default "user-read-email" scope.

Expected behavior

The Spotify provider should respect the authorization.params.scope option, similar to other OAuth providers in Auth.js. When custom scopes are specified, they should be included in the authorization URL sent to Spotify.

The expected behavior would allow users to configure Spotify scopes like this:

Spotify({
   authorization: {
      params: {
         scope: 'user-top-read user-read-email',
      },
   },
})

This configuration should result in an authorization URL that includes all the specified scopes, allowing users to request the necessary permissions from Spotify without having to override the entire authorization URL.

sshuvoo avatar Aug 28 '24 13:08 sshuvoo

Should be fixed holistically, not just for Spotify. PRs welcome!

balazsorban44 avatar Aug 31 '24 21:08 balazsorban44

This issue was marked with the good first issue label by a maintainer.

This means that it is a good candidate for someone interested in contributing to the project, but does not know where to start.

Have a look at the Contributing Guide first.

This will help you set up your development environment to get started. When you are ready, open a PR, and link back to this issue in the form of adding Fixes #1234 to the PR description, where 1234 is the issue number. This will auto-close the issue when the PR gets merged, making it easier for us to keep track of what has been fixed.

Please make sure that - if applicable - you add tests for the changes you make.

If you have any questions, feel free to ask in the comments below or the PR. Generally, you don't need to @mention anyone directly, as we will get notified anyway and will respond as soon as we can)

[!NOTE]
There is no need to ask for permission "can I work on this?" Please, go ahead if there is no linked PR :slightly_smiling_face:

github-actions[bot] avatar Aug 31 '24 21:08 github-actions[bot]

possibly need a fix here:

https://github.com/nextauthjs/next-auth/blob/main/packages/core/src/lib/utils/merge.ts

and/or

https://github.com/nextauthjs/next-auth/blob/6377582636401060842f6ff918741440f049a6ff/packages/core/src/lib/utils/providers.ts#L132

balazsorban44 avatar Aug 31 '24 21:08 balazsorban44

possibly need a fix here:

https://github.com/nextauthjs/next-auth/blob/main/packages/core/src/lib/utils/merge.ts

I believe the code is related to the PR I submitted (https://github.com/nextauthjs/next-auth/pull/11685) and the issue discussed https://github.com/nextauthjs/next-auth/issues/9448#issuecomment-2183879126.

Zamoca42 avatar Sep 03 '24 16:09 Zamoca42

https://github.com/nextauthjs/next-auth/pull/11685 is merged, will be out in the next release! Thank you @Zamoca42!

balazsorban44 avatar Sep 15 '24 19:09 balazsorban44

Oh hey, glad this was fixed!

When I wrote that comment, I noticed that there were a few other issues related to custom authorization configs for other providers. The adapters were being patched with the new authorization object shape; moving forward, providers that still have their original string primitive authorization URLs should allow configuration as per the docs

Thanks @Zamoca42

nic-vo avatar Oct 31 '24 19:10 nic-vo

@balazsorban44 did this get fixed? I just started using AuthJS and it still seems to be a problem - the scope is hardcoded in the spotify.ts:

"https://accounts.spotify.com/authorize?scope=user-read-email",

kyds3k avatar Jan 03 '25 21:01 kyds3k

@kyds3k it seems that the hardcoded default url is overwritten internally when making the request to the signin route - it reads the params from the authorization object and adds them to the search query in the getAuthorizationUrl function but it would be nice to also update the authorization config when the provider is parsed so it can also serve as a source of truth to read the final authUrl (ie. for refreshes)

inferrinizzard avatar Jul 11 '25 16:07 inferrinizzard