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

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

Open MathiasCiarlo opened this issue 6 years ago • 8 comments

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? 😄

MathiasCiarlo avatar Sep 25 '19 00:09 MathiasCiarlo

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

pi0 avatar Oct 07 '19 09:10 pi0

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

MathiasCiarlo avatar Oct 08 '19 18:10 MathiasCiarlo

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

jbmolle avatar Dec 09 '19 10:12 jbmolle

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

riccardogioratoatoms avatar Sep 17 '20 14:09 riccardogioratoatoms

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

vehagn avatar Oct 16 '20 14:10 vehagn

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 https://github.com/nuxt-community/auth-module/issues/713#issuecomment-800974833 that schema solution worked for us with todays version of @nuxtjs/auth-next. Now we can use runtime env variables for our auth endpoints.

acarlsson avatar Aug 12 '21 14:08 acarlsson

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

wensaint avatar Jun 16 '22 09:06 wensaint

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'
        }
      }
    }
  }
}

rijnhard avatar May 07 '23 12:05 rijnhard