Skip to content
downpipes docs

Sign in to downpipes with Auth0

downpipes signs people in to the console against your Auth0 tenant over OpenID Connect. The Auth0 preset fills the endpoints, scopes and claim names, so you supply your tenant domain, the client id and the client secret, and register one callback URL at Auth0. The shared add-a-connection mechanics, the two secret modes and the pre-save test live on Connect OIDC or OAuth2.

What you need

  • An Auth0 tenant where you can create an application (a tenant admin).
  • Owner access to the downpipes console, since connection management is owner-only and asks for a step-up sign-in.

Set it up

  1. In the Auth0 Dashboard, open Applications, then Create Application. Name it (for example “downpipes”), choose Regular Web Application, and Create. Registering it as a Regular Web Application is what permits the confidential-client token exchange the engine performs.
  2. On the Settings tab, under Application URIs, paste your downpipes callback URL into Allowed Callback URLs. The callback URL is your console origin followed by /admin/oidc/callback/<connId>, for example https://console.example.com/admin/oidc/callback/auth0, and the console shows the exact value when you add the connection.
  3. From the top of Settings, copy the Domain (include the region, for example your-tenant.us.auth0.com), the Client ID and the Client Secret.
  4. In the downpipes console, open the external identity providers screen (/access/idp), choose the Auth0 tile and Add a connection. This is owner-only and asks for a step-up sign-in.
  5. Paste your Auth0 domain, the client id and the client secret. Leave the roles-claim namespace blank for sign-in only.
  6. Run Test connection to confirm discovery and the signing keys are reachable, then Add the connection.

Group-to-role mapping

Auth0 emits no roles or groups by default, and it silently drops any custom claim that is not namespaced, so membership reaches downpipes only through a namespaced claim you add. Set a roles-claim namespace on the connection (a URL ending in a slash, for example https://app.yourcompany.com/), then add a Login / Post Login Action in Auth0 that writes a namespaced claim onto the ID token. The claim key is the namespace followed by roles, so the example namespace produces https://app.yourcompany.com/roles, which is exactly the key the engine reads.

exports.onExecutePostLogin = async (event, api) => {
  const namespace = "https://app.yourcompany.com/";
  api.idToken.setCustomClaim(namespace + "roles", event.authorization?.roles ?? []);
};

Deploy the Action and add it to the Login flow, then assign roles to people under User Management, Roles. Map each Auth0 role onto a downpipes role on Group-to-role mapping. Leave the namespace blank on the connection for sign-in only, with roles assigned per person inside downpipes.

Good to know

  • The issuer needs its trailing slash. Auth0’s issuer is https://<domain>/ with the slash, and the preset adds it; dropping the slash is the classic Auth0 iss mismatch that fails verification.
  • Put the region in the domain. Use the full tenant host including the region (your-tenant.us.auth0.com, .eu.auth0.com) or your Auth0 custom domain, or discovery fails.
  • A non-namespaced custom claim never arrives. Auth0 drops it without warning, so a bare roles claim carries nothing; only the namespaced key set by the Action reaches downpipes.
  • Without the Post-Login Action, sign-in still works. People land at the viewer floor until you map a role.

Last updated .