feat(oauth2): Add support for runtime and environment-specific options

[MathiasCiarlo]

The problem

Currently all the scheme options are baked into the bundle during build.
Because of this - you can't use the same bundle in multiple environments (e.g. test and prod) if you have options that are environment-specific.

Example use case

Some organisations have dedicated auth servers for each environment:
Prod: login.example.com/oauth-path
Test: login-test.example.com/oauth-path

The developers want to deploy the same bundle in all environments, and supply an environment variable AUTH_URL which points to the correct url.

The developers can't set authorization_endpoint: process.env.AUTH_URL in the options, because this variable is not known at build time.

Proposed solution

To solve this issue, I propose we introduce a new option: _runtimeOptions, which is evaluated runtime:

auth: {
  strategies: {
    yourFavoriteProvider: {
      _scheme: 'oauth2',
      scope: ['openid', 'profile', 'email'],
      _runtimeOptions: () => {
        return {
          client_id: process.env.CLIENT_ID,
          authorization_endpoint: process.env.AUTH_URL + '/auth',
          access_token_endpoint: process.env.AUTH_URL + '/token',
          userinfo_endpoint: process.env.AUTH_URL + '/userinfo'
        }
      }
    }
  }
}

The _runtimeOptions function will be evaluated and merged with the other options during the initial request to the server.

Security concerns

I evaluated the risk of creating a function runtime (see eval is evil), but I think it should be fine because the function is only evaluated at build time, removing the risk of XSS.

Alternative solution

If we can't do it this way, maybe we could supply a list of environment variable name mappings?:

options: {
  _scheme: 'oauth2',
  _optionsFromEnvironment: {
    client_id: AUTH_CLIENT_ID,
    authorization_endpoint: AUTH_ENDPOINT,
    token_endpoint: AUTH_TOKEN_ENDPOINT
  }
}

i.e: client_id would be mapped to process.env.AUTH_CLIENT_ID

Although this method is less flexible, it does not rely on creating functions runtime.

Caveats

• Only supported in universal mode (I think we can get around this, though)

What about local scheme?

This feature is very easy to add for local schemes, but I could not come up with a use case, so I left it out. Please tell me if you have a use case and think it should be available for local schemes 🙂

What do you think about this proposal? 😄

[pi0]

Hi @MathiasCiarlo. Thanks for this PR. I think we can support it for both SPA and Universal modes (but not generated). So triggered a core team discussion if we can have it in core

[MathiasCiarlo]

Thanks, @pi0! Excited to hear what you guys figure out 😄

[jbmolle]

Hi,
What is the status of this PR?
We've developed an app with Next Auth and we would like to package it with Docker and environment variables to have one Docker image for multiple environment.
For that we need this PR.
Thanks,
JB

[riccardogioratoatoms]

Any news on this PR?
I would need this feature too or this plugin is not usable without a dynamic endpoint at runtime.

[vehagn]

I'm patiently awaiting this feature as well. Is there anything I can do to help with it getting merged, @pi0 ?

[acarlsson]

Me and the team are also awaiting this feature. We need it for dynamic API endpoints at runtime. Any idea when it will be merged? @pi0

EDIT: Found this comment #713 (comment) that schema solution worked for us with todays version of @nuxtjs/auth-next. Now we can use runtime env variables for our auth endpoints.

[wensaint]

I want to change the cookie options at runningtime, Any news on this PR?

[rijnhard]

Would this cover for example setting window.location? this way the settings can be configured based on where its deployed. e.g.

auth: {
  strategies: {
    yourFavoriteProvider: {
      _scheme: 'oauth2',
      scope: ['openid', 'profile', 'email'],
      _runtimeOptions: () => {
        return {
          redirectURI: window.location.origin + '/logged-out'
        }
      }
    }
  }
}