github nextauthjs/next-auth v4.0.0-next.20

latest releases: @auth/azure-tables-adapter@1.7.3, @auth/d1-adapter@1.7.3, @auth/dgraph-adapter@2.7.3...
pre-release3 years ago

4.0.0-next.20 (2021-08-04)

Features

BREAKING CHANGES

  • events: Two event signatures changed to use named params, signOut and updateUser:
// [...nextauth].js
...
events: {
- signOut(tokenOrSession),
+ signOut({ token, session }), // token if using JWT, session if DB persisted sessions.
- updateUser(user)
+ updateUser({ user })
}
  • providers: Basecamp provider is removed. See the explanation here

ALL OAuth providers' profile callback is expected to only return these fields by default from now on: id, name, email, and image at most. Any of these missing values should be set to null.

The following new options are available:

  1. authorization (replaces authorizationUrl, authorizationParams, scope)
  2. token replaces (accessTokenUrl, headers, params)
  3. userinfo (replaces profileUrl)

These three options map nicely to the OAuth spec's three endpoints for

  1. initiating the login flow
  2. retrieve OAuth tokens
  3. retrieve user information

They all take the form of EndpointHandler:

type EndpointRequest<C, R> = (
  context: C & {
    /** `openid-client` Client */
    client: Client
    /** Provider is passed for convenience, ans also contains the `callbackUrl`. */
    provider: OAuthConfig & {
      signinUrl: string
      callbackUrl: string
    }
  }
) => Awaitable<R>

/** Gives granular control of the request to the given endpoint */
type AdvancedEndpointHandler<P extends UrlParams, C, R> = {
  /** Endpoint URL. Can contain parameters. Optionally, you can use `params`*/
  url?: string
  /** These will be prepended to the `url` */
  params?: P
  /**
   * Control the corresponding OAuth endpoint request completely.
   * Useful if your provider relies on some custom behavior
   * or it diverges from the OAuth spec.
   *
   * - warning **This is an advanced option.**
   * You should **try to avoid using advanced options** unless you are very comfortable using them.
   */
  request?: EndpointRequest<C, R>
}

/** Either an URL (containing all the parameters) or an object with more granular control. */
type EndpointHandler<P extends UrlParams, C = any, R = any> =
  | string
  | AdvancedEndpointHandler<P, C, R>

In case of authorization, the EndpointHandler can define the params as AuthorizationParameters

Note: authorization does not implement request yet. We will have to see if there is demand for it.

From now on, instead of using the ... spread operator when adding a new built-in provider, the user is expected to add options as a property at the end of the default config. This way, we can deep merge the user config with the default one. This is needed to let the user do something like this:

MyProvider({
  clientId: "",
  clientSecret: "",
  authorization: { params: {scope: ""} }
})

So even if the default config defines anything in authorization, only the user-defined parts will be overridden.

Don't miss a new next-auth release

NewReleases is sending notifications on new releases.