Auth0 Deployment Plan

TODO: collapasable, copyable, download, etc

I need to write a technical doc about how our new authentication works. I'm going to give you a few different assets. I need you to read theml, think about them, and then follow the last instruction. AUTH.md

Auth

Deductive App UI always uses Auth0 for authentication, but it can be deployed with a few different types of Authentication:

  • email + password credentials
  • Google OAuth
    • This can be setup as a Social login
    • or an an Enterprise SSO login

Only one authenticaiton mode is supported at any given deplyment. These can be modified in the Auth0 dashboard.

App UI developers (localhost:3000) will use either Google OAuth (Deductive dogfood mode) or email + password (dev and testing customer based setup).

localhost:8081 docker images will always use Google OAuth.

Deductive staging and production (turing) will use Google OAuth.

Customer deployments will use a customer specific Auth0 application credentials.

Auth0

Auth0 requires the following environment variables to be set:

  • AUTH0_SECRET
  • AUTH0_BASE_URL
  • AUTH0_ISSUER_BASE_URL
  • AUTH0_CLIENT_ID
  • AUTH0_CLIENT_SECRET

See ../env.example for current developer localhost app credentials

Setting up new Auth0 "Applications"

Each environment such as a customer or a deployment environment should get a new Auth0 "Application".

Here is the steps for setting one up

  1. Go to the Auth0 Dashboard https://manage.auth0.com/dashboard/
  2. Click "Applications" in the left sidebar
  3. Click Create Application
  4. Choose "Regular Web Application"
  5. Click Create
  6. Click the "Connections" tab
  7. Setup connections. See next section
  8. Click Settings Tab
  9. Fill in "Allowed Callback URLs" with something like http://localhost:3000/api/auth/callback
  10. Fill in "Allowed Logout URLs" with http://localhost:3000
  11. Fill in "Allowed Web Origins" with http://localhost:3000

Substitute http://localhost:3000 with the domain you are using that is customer facing. So https://deductive.thoughtspot.com for example.

Setting up Connections

Google OAuth

Setting up your own Developer App credentials

We setup authentication following the NextJs Auth0 instructions.

When creating the application, choose web application and not SPA.

For callback URLs for our two development modes for example, specificy both :3000 and :8081

http://localhost:3000/api/auth/callback,http://localhost:8081/api/auth/callback

And the same for logout url

http://localhost:3000,http://localhost:8081

Again, the protocol, domain, and port should match what the user is putting in the brower's address bar. So customer deployments that will be https://deductive.thoughtspot.com for example.

ORIGIN ENV Variable

The ORIGIN env variable should be set to the origin of the production or staging website. In web standards terminology, an origin refers to the protocol, hostname, and port. Port can be ommited when standard ports such as 443 are being used for a protocol like https.

Example:

ORIGIN=https://staging.deductive.ai

I need to write a technical doc about how our new authentication works. I'm going to give you a few different assets. I need you to read theml, think about them, and then follow the last instruction. AUTH.md

Auth

Deductive App UI always uses Auth0 for authentication, but it can be deployed with a few different types of Authentication:

  • email + password credentials
  • Google OAuth
    • This can be setup as a Social login
    • or an an Enterprise SSO login

Only one authenticaiton mode is supported at any given deplyment. These can be modified in the Auth0 dashboard.

App UI developers (localhost:3000) will use either Google OAuth (Deductive dogfood mode) or email + password (dev and testing customer based setup).

localhost:8081 docker images will always use Google OAuth.

Deductive staging and production (turing) will use Google OAuth.

Customer deployments will use a customer specific Auth0 application credentials.

Auth0

Auth0 requires the following environment variables to be set:

  • AUTH0_SECRET
  • AUTH0_BASE_URL
  • AUTH0_ISSUER_BASE_URL
  • AUTH0_CLIENT_ID
  • AUTH0_CLIENT_SECRET

See ../env.example for current developer localhost app credentials

Setting up new Auth0 "Applications"

Each environment such as a customer or a deployment environment should get a new Auth0 "Application".

Here is the steps for setting one up

  1. Go to the Auth0 Dashboard https://manage.auth0.com/dashboard/
  2. Click "Applications" in the left sidebar
  3. Click Create Application
  4. Choose "Regular Web Application"
  5. Click Create
  6. Click the "Connections" tab
  7. Setup connections. See next section
  8. Click Settings Tab
  9. Fill in "Allowed Callback URLs" with something like http://localhost:3000/api/auth/callback
  10. Fill in "Allowed Logout URLs" with http://localhost:3000
  11. Fill in "Allowed Web Origins" with http://localhost:3000

Substitute http://localhost:3000 with the domain you are using that is customer facing. So https://deductive.thoughtspot.com for example.

Setting up Connections

Google OAuth

Setting up your own Developer App credentials

We setup authentication following the NextJs Auth0 instructions.

When creating the application, choose web application and not SPA.

For callback URLs for our two development modes for example, specificy both :3000 and :8081

http://localhost:3000/api/auth/callback,http://localhost:8081/api/auth/callback

And the same for logout url

http://localhost:3000,http://localhost:8081

Again, the protocol, domain, and port should match what the user is putting in the brower's address bar. So customer deployments that will be https://deductive.thoughtspot.com for example.

ORIGIN ENV Variable

The ORIGIN env variable should be set to the origin of the production or staging website. In web standards terminology, an origin refers to the protocol, hostname, and port. Port can be ommited when standard ports such as 443 are being used for a protocol like https.

Example:

ORIGIN=https://staging.deductive.ai

Docker file diff

  • ENV NEXTAUTH_URL=http://localhost:8081/
  • ENV - NEXTAUTH_SECRET=98db4f30dc8c6e9f9dcc3bf56d7fc250b0eecafe1370339e0249f696d2c862c1

  • Replace with your own, or reuse Deductive-dev

  • ENV GOOGLE_OAUTH_CLIENT_ID=532462978790-khsmqpabem82k4ru1ikl7591h8idnvu2.apps.googleusercontent.com
  • ENV GOOGLE_OAUTH_SECRET=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
  • ENV AUTH0_SECRET='97d9907bd277251c701eeac5d8193206a73a533c31ea08a7c6d7bb9cdab4bbf7'
  • ENV AUTH0_BASE_URL='http://localhost:8081'
  • ENV AUTH0_ISSUER_BASE_URL='https://dev-z1jdkzov13mo31b7.us.auth0.com'
  • ENV AUTH0_CLIENT_ID='Rkh5TTPbMBKMArV81Ym47MIXDm0wbhVw'
  • ENV AUTH0_CLIENT_SECRET='vyMor3WWX_jI50RJ1zfBsZB7mIx_1zDnM6wiKG8QXNaw3a11qiYqlNwsGNKqqXo1'

Background: Our operations team is developing a more secure secrets management platform that will be ready May 30th. I would like to deploy Auth0 sooner and use the old config management system. The old system is to store configs in a private github repository. This is somewhat secure, but less secure than the future secrets management platform. Please point out that we should deploy sooner so we can test Auth0 end to end in customer environments. If we are concerned about security, we can alwys reset the secrets. The downside effect is to log.out all existing sessions once secrets are rotated. Lastly the two env variables that are most sensative end in _SECRET.

You are a principal engineer. Please write up a tech doc focused around documenting these details and making the argument to deploy sooner and not to wait for the secrets management configuration. Please call it Auth0 deployment plan. Include a section about how we will re-deploy this config. as part of the secrets management migration. To write a comprehensive technical document based on the provided AUTH.md, you'll need to structure# Auth0 Deployment Plan

Overview

As part of enhancing our authentication capabilities, we are transitioning from using Google OAuth credentials to Auth0. This document outlines the deployment plan for integrating Auth0 into our environments, and the strategic advantage of an earlier deployment, even before our new secrets management platform is operational.

Current Authentication Method

Our current method uses environment-specific Google OAuth credentials, which are managed through environment variables set directly in our Docker configurations.

Proposed Change to Auth0

Rationale

Auth0 provides a more flexible and robust authentication framework, allowing us to support various authentication methods including email and password credentials, and enterprise-level single sign-on through Google OAuth. This enables a unified approach to authentication across different environments and customer deployments.

Configuration Details

The transition involves replacing existing environment variables related to Google OAuth with those required by Auth0:

  • AUTH0_SECRET
  • AUTH0_BASE_URL
  • AUTH0_ISSUER_BASE_URL
  • AUTH0_CLIENT_ID
  • AUTH0_CLIENT_SECRET

The new configuration will allow us to handle authentication more securely and with greater versatility across development, staging, and production environments.

Security Considerations

Currently, our configuration secrets are stored in a private GitHub repository. While this method offers some level of security, it is not as robust as the upcoming secrets management platform we plan to implement. Despite this, it is recommended to proceed with the Auth0 deployment prior to the new platform being ready for several reasons:

  1. Early Testing and Integration: Deploying Auth0 now allows us to test the system end-to-end in all customer environments, ensuring that any issues can be addressed well in advance.
  2. Iterative Security Enhancements: Initial deployment using the current method allows us to transition smoothly to the new secrets management system once it's online, without disrupting existing operations.
  3. Resetting Secrets: Any concerns regarding the security of the stored secrets can be mitigated by resetting the Auth0 secrets once the new secrets management platform is operational. This would invalidate all existing sessions, which is a manageable downside as it ensures all users are authenticated under the new system.

Deployment Strategy

Initial Deployment

  1. Update Environment Variables: Update the Docker configurations to use the new Auth0 variables.
  2. Application Settings in Auth0: Set up new Auth0 applications for each environment and configure connections as per the documentation provided.
  3. Deployment and Monitoring: Deploy the changes across all environments and monitor for any authentication issues.

Post-Deployment

Once the secrets management platform is operational, we will:

  1. Migrate Secrets: Move all Auth0 related secrets from the GitHub repository to the new management platform.
  2. Reset Secrets: Reset the Auth0 secrets to new values managed through the platform.
  3. Update Environment Configurations: Adjust the environment variables to point to the new secrets locations.
  4. Re-deployment: Roll out the updated configurations across all environments.

Conclusion

Deploying Auth0 prior to the complete readiness of the secrets management platform is strategically beneficial. It allows us to fully test the system in production environments, ensuring a smooth transition. By planning for an iterative update to our secrets management approach, we can maintain security while improving our system's capabilities and reliability.This is really good, but can you re-write just the Initial Deployment section to include a list of ENV variables to be removed?### Initial Deployment

  1. Remove Existing Environment Variables: Prior to updating the Docker configurations, remove the following environment variables related to the old Google OAuth setup:

    • NEXTAUTH_URL
    • NEXTAUTH_SECRET
    • GOOGLE_OAUTH_CLIENT_ID
    • GOOGLE_OAUTH_SECRET

  2. Update Environment Variables: Introduce the new Auth0-specific variables into the Docker configurations to support the new authentication method:

    • AUTH0_SECRET
    • AUTH0_BASE_URL
    • AUTH0_ISSUER_BASE_URL
    • AUTH0_CLIENT_ID
    • AUTH0_CLIENT_SECRET

  3. Application Settings in Auth0: Configure new Auth0 applications for each environment. Set up the connections, callback URLs, logout URLs, and web origins as outlined in the Auth0 setup documentation provided.

  4. Deployment and Monitoring: Deploy the changes across all environments and monitor the authentication processes closely to ensure that there are no disruptions or security issues.

Auth0 Deployment Plan created at Tue Jan 20 1970 20:33:37 GMT+0000 (Coordinated Universal Time)

Related Chats

Auth0 Deployment Plan 0.999

0.526

Google OAuth 401 Error 0.449

React Auth Types Enum 0.434

Dockerfile for PostgreSQL 16.1 0.397

Google OAuth Rate Limits 0.330

Docker ENV Variables Not Set 0.313

API Key Security Solutions 0.308

Sign CIIAA or Not? 0.303

SwApp para Compartir Datos 0.282