Skip to main content

[Deprecated] Auth0 Authentication

Auth0​

Auth0 is a flexible, drop-in solution to add authentication and authorization services to your applications. For more information, refer to the Auth0 Documentation.

Tenants​

  • Staging: dev-7zs2ya4iaqso56ya
  • Prod: legionsecurity

An Auth0 tenant is a logical environment that encapsulates all identity management configurations, including applications, users, connections, and settings. Each tenant is isolated, allowing for separate management of environments like development, testing, and production. Tenants enable customization of authentication experiences and policies, ensuring tailored solutions for different use cases or client needs.

Organizations​

Metadata​

  • each organization has metadata in the format be=<BE_URL> and wa=<WEBAPP_URL>.
  • be is used to set the backend server the extension/webapp will use for api calls
  • wa is used in the extension to set the link for audit view

The process of adding a new customer (org):​

  1. Create a new org
  2. Add metada to the org
  3. Enable connection in the organization
  4. Add a new user
  5. Add user as a member to the org and set role for the user in the organization
  • Notice: a role can be assinged directly to user or to user in the context of an organization. We need the role for the user in the context of an organization.

Logs​

Auth0 logs are useful and can help debug login sessio. Those are located in Auth0 Dashboard > Monitoring > Logs

Auth in Chrome Extension​

Authentication Flow:​

  • Method: Authorization Code Flow with Proof Key for Code Exchange (PKCE).
  • Reason for PKCE: Client secrets cannot be securely stored in the extension.

The Authorization Code Flow with Proof Key for Code Exchange (PKCE) enhances security for public clients (like mobile or single-page applications) by requiring a dynamically generated code verifier. This verifier is used along with the authorization code to obtain access tokens, preventing interception attacks.

Authorization &amp; PKCE For more details, visit the Auth0 PKCE Documentation.

Implementation Details:​

  1. Auth0 SDK: Not used. Instead, Chrome's chrome.identity API is utilized.
  2. Authentication Process:
    • Login: Uses launchWebAuthFlow to open the Auth0 login page.
    • Redirect URL: Uses getRedirectURL which is formatted as https://<extension_id>.chromiumapp.org.
    • Auth0 Configuration: Redirect URLs, callback URLs, etc., are all configured using the extension's URL format.
  3. Auth0 Application Configuration:
    • Application Type: Regular Web App.
    • Grant Types: Authorization Code and Refresh Token.
    • Client Authentication: None (to allow PKCE, no client secret required).

Login Result:

  1. Access Token: Used to send to the backend API as an authorization header. The backend verifies this access token.
  2. ID Token: Contains user details, backend URL (retrieved from Auth0 organization metadata), name, etc.
  3. Refresh Token: Used periodically (and ad hoc) to refresh the tokens.

Utility Functions in authSertvice.ts:

  • Login: Handles user login in authenticateUser().
  • Token Exchange: Exchanges authorization code for access and refresh tokens.
  • Logout: Manages user logout process.
  • Store Tokens: Access token and its expiration time are stored in the extension's session storage, while refresh token is stored in local storage.

Usage:

  • Side Panel: Utilizes authentication functions to manage user sessions. Stores the tokens in recoil (and also update the storage if needed) and use them for api calls to api server.
  • Background Script: Implements token refresh periodically and session management in the background. Use the access token for api calls to api server. Stores the tokens in the stroage and sends a token update msg to the side panel to update the recoil states.
  • Content Script: Use the api tokens from the session for api calls to the api server, and just like the backgrund script sends a token update msg to the side panel if needed

Authentication in the API Server​

Each API request must include an Authorization header in the format Bearer <base64_jwt_access_token>. The access token is verified by fetching public keys from the Auth0 /.well-known/jwks.json endpoint, from staging/prod tenant according to configuration in .env files. This verification ensures that the token is correctly signed and that its expiration is valid.

Authentication in the Webapp​

Authentication Flow:

  • Method: Authorization Code Flow with Client Secret.
  • Client Secret The Client Secret is stored on NextJs Backend.

Implementation Details:

  1. Next-Auth SDK: AKA AuthJs. Handles session management and token retrieval.
  2. Authentication Process:
    • Next-Auth: The sdk is taking care of the authentication flow.
    • Environment Variables The following variable are used:
AUTH0_CLIENT_ID=''
AUTH0_ISSUER_BASE_URL=''
AUTH0_DOMAIN=''
AUTH0_AUDIENCE= ''
NEXTAUTH_SECRET=''
AUTH0_CLIENT_SECRET=''
  • MiddleWare Checks for token existence on each next-be endpoint call, and redirects to the login page if not present.
  • Protected Api Calls There are 3 options for api calls in webapp:
  1. Calling the api from a client component using useSession() hook provided by next-auth
  2. Calling the api from a next-api, so the component is calling the next be api and it calls the server api
  3. Calling the api from a server component using getToken() provided by next-auth

Auth0 configuration and Vercel For the webapp we have 4 different deploy options:

  1. production
  2. staging (which is preview on branch main)
  3. preview
  4. local

The 3 first options are deployed using Vercel, and hence we set environment variable relevant to authentication in Vercel Dashboard

Environments Matrix​

Auth0 Matrix of Auth0 tenants * User (Be_Url) * Webapp/Extension * Backend.

Gotchas

  1. To run the webapp locally with npm run dev (runs on port 3001) or on any port different than 3000 you'll have to configure NEXTAUTH_URL=http://localhost:<YOUR PORT> in .env.local file.
  2. BE and public keys restriction:
    • Staging webapp/extension can only use Staging BE or local BE that is configured to take keys from staging tenant.
    • Prod webapp/extension can only use Prod BE or local BE that is configured to take keys from prod tenant. For example, Staging webapp cannot work with Prod BE.

Auth0 Management API​

We use the mgmt api to fetch the organization data in the BE. We fetch a token using the Machine-2-Machine application client id and secret. We use the token to fetch the organization details via mgmt api. For that to work locally we need to add MGMT_CLIENT_SECRET = 'client_secret' to .env file

The client secret is taken from Auth0 UI, non prod tenant:

Applications > API Explorer Application > Client Secret