Can the OktaAuthModule be configured at runtime?

Questions
1

Hello,

I’ve run into an issue where the solution would be to be able to configure the OktaAuthModule at runtime, if that even makes sense.

In Angular, we have the two default environments: dev (default) and prod (ng build --prod). When it comes time to release, and our continuous integration says our tests pass on master, I use Octopus to generate a release by first deploying to our dev staging environment. If all is well, I deploy to our test staging environment. After more checks there, I deploy this release to production and all is happy in the world.

The problem is this: each of those staging environments and the production environment have their own domain (i.e. dev.domain.com, test.domain.com, and .domain.com). This comes into play when I have to configure the OktaAuthModule in app.module.ts. When I deploy to my dev staging environment, then try to log in, I get redirected to my production uri instead of my dev one (app.module.ts):

OktaAuthModule.initAuth({
  issuer: environment.oktaURL,
  redirectUri: `${environment.rootURI}/implicit/callback`,
  clientId: '<client-id>'
})

What we’ve done to solve this in other places is to have a settings.json file in our bundled application that is accessible through a AppSettingsService that makes local http calls to the json file to retrieve configuration settings that Octopus does a Find and Replace on during the deployment process. But I’m assuming I can’t take this same approach here because this is actually happening before I can inject any of my services, correct?

I’ve thought of some alternatives, but I don’t like them:

have a separate build for each staging environment in Angular.
Octopus provides deploying the same application bundle to several staging environments very easily. We’d be defeating the purpose of using a deployment system like this if we had to go make another build and have a separate release for each staging environment. So I don’t WANT to do this.
Have a complicated Find and Replace step in Octopus for looking for the OktaAuthModule import statement and replace the redirectUri with the right one.
I’m afraid of this one because I don’t know what app.module.js looks like well enough to to a Find and Replace rule that works 100% of the time.
Any ideas?

2

@tom, any ideas on this one?

3

This question is probably above my pay grade :slight_smile:

How I’ve seen most angular applications do this is they, unfortunately, need to build it themselves. They do a call to a configuration file on the server to configure the modules.

Two ways that I’ve seen in live applications…

  • Make an http.get to a configuration file on the server
  • Use an environment.js file that is loaded before your angular app that sets some values, that you can modify during build time per environment.

I’m not super familiar with octopus functionality though. They might have some other ideas.

4

That’s pretty much what we are doing. We have a json file that comes in the assets folder of the application and we let octopus Find and Replace values for you there. We successfully use this approach for runtime configuration. Problem with this approach and configuring the OktaAuthModule is that the import of the module doesn’t give me access to any of these settings. There is a service we wrote wrapped around going and getting the settings like this:

imports: [
  ...
  OktaAuthModule.initAuth({
    issuer: environment.oktaURL,
    redirectUri: `${environment.rootURI}/implicit/callback`, // Can't reach AppSettingsService from here.
    clientId: environment.oktaClientID
  })
],
providers: [
  ...
  {
    provide: APP_INITIALIZER,
    useFactory: initializeSettings,
    multi: true,
    deps: [AppSettingsService]
  },
  ...
],
...

export function initializeSettings(settingsService: AppSettingsService) {
  return () => settingsService.loadConfiguration(); // HTTP call goes here.
}
5

As a learning experience for me, could you explain why just making the config object in the OktaAuthService class publically accessible would not be a suitable solution? Is there any negative side-effects of allowing this to be configurable at run-time?

The previous libraries I was using for auth with Okta allowed for all this configuration once you were ready to use it, after the application had been fully bootstrapped and running.

6

I stopped using the OktaAuthModule and just rolled my own pretty easily still using the the Okta Auth JS SDK https://github.com/okta/okta-auth-js which the OktaAuthModule uses anyway.

7

@ferrand is your own module consumable? Are you sharing it? I could at least use some inspiration if we end up going down that road as well.

8

My module is not, but there is some sample guidence here https://developer.okta.com/code/angular/okta_angular_auth_js.html plus you can always take the source here https://github.com/okta/okta-oidc-js/tree/master/packages/okta-angular
and fork your own

9

Hi, were you able to find a solution to this issue, we have the same architecture as you to use Octopus and replace config values based on environment. Could you please share what you end up doing