Reduce user facing provider APIs

[balazsorban44]

Currently, there are some "magical" 🧙 fields only utilized by specific providers. We could handle these edge cases internally instead. All providers have an id, which we can use to switch on different behaviors. It would also make it easier to keep a TypeScript provider interface simple, without the need for Discriminated Union or similar

Some of these fields and which provider(s) use them (introduced in which PR):

• additionalAuthorizeParams: slack (Update Slack provider to use V2 OAuth endpoints #895)
• accessTokenGetter: slack (Update Slack provider to use V2 OAuth endpoints #895)
• setGetAccessTokenAuthHeader: okta, identity-server4 (adding support for Okta as a provider #213)
• setGetAccessTokenProfileUrl: mailru (feat(provider): Add Mail.ru OAuth Service Provider and Callback snippet #522 not yet implemented)
• clientSecretCallback: apple (Refactor and document Apple provider #176)
• state: apple (Refactor and document Apple provider #176)
• prepareProfileRequest: bungie (feat(provider): Add Bungie #589)

[balazsorban44]

@cathykc As the original author of #895, I would like to ask you, how strongly do you feel about additionalAuthorizeParams being a provider property, instead of using the (new) third argument of the signIn client function?

next-auth/src/client/index.js

Lines 226 to 242 in f2ad693

	const signIn = async (provider, args = {}, authParams = {}) => {
	const baseUrl = _apiBaseUrl()
	const callbackUrl = (args && args.callbackUrl) ? args.callbackUrl : window.location
	const providers = await getProviders()
	// Redirect to sign in page if no valid provider specified
	if (!provider || !providers[provider]) {
	// If Provider not recognized, redirect to sign in page
	window.location = `${baseUrl}/signin?callbackUrl=${encodeURIComponent(callbackUrl)}`
	} else {
	let signInUrl = (providers[provider].type === 'credentials')
	? `${baseUrl}/callback/${provider}`
	: `${baseUrl}/signin/${provider}`
	if (authParams) {
	signInUrl += `?${new URLSearchParams(authParams).toString()}`
	}

Example:

<button
  onClick={() => signIn("slack", {}, {user_scope: 'identity.basic,identity.email,identity.avatar'})}
>
  Login
</button>

Right now, there are 2 ways of doing it, and we could eventually keep both, I was just curious about your opinion.
Setting authorize params may actually be useful for several providers and can be a general thing in contrast to the other, above mentioned magical provider properties, so I may even be OK with removing the authParams from the client signIn function instead. I might want to rename it to just authParams or authorizeParams removing the additional prefix.

UPDATE:
After giving it some thought, I think it makes more sense to keep your change and remove it from the signIn client-side function.

[balazsorban44]

@cathykc when #1023 will be merged, the name will change from

additionalAuthorizeParams to authorizationParams. This plays better with the already present authorizationUrl.

I changed the slack provider respectively, so no changes will be needed.

[github-actions]

🎉 This issue has been resolved in version 3.2.0-canary.15 🎉

The release is available on:

• GitHub release
• npm package (@canary dist-tag)

Your semantic-release bot 📦🚀

[github-actions]

🎉 This issue has been resolved in version 3.3.0-canary.1 🎉

The release is available on:

• GitHub release
• npm package (@canary dist-tag)

Your semantic-release bot 📦🚀