Skip to content
Notifications
Clear all

Real experience using Auth0 with a mono-repo and microservices

2 Posts
2 Users
0 Reactions
4 Views
(@ci_cd_crusader)
Reputable Member
Joined: 1 month ago
Posts: 139
Topic starter   [#19586]

Having recently implemented Auth0 as our centralized identity provider across a suite of 12 containerized microservices in a mono-repo, I wanted to share some concrete CI/CD and architectural observations. The promise of offloading authentication is compelling, but the integration patterns—especially in a mono-repo—introduce specific challenges.

Our setup uses a shared library (`@our-org/auth`) for the Auth0 SDK configuration and token validation logic. This ensures consistency but requires careful version management. The main hurdle was managing tenant configuration across multiple deployment environments (dev, staging, prod) without embedding secrets in our Docker builds.

Here’s a snippet from our GitHub Actions workflow for a service, highlighting the environment-specific configuration injection:

```yaml
- name: Build and Push Docker Image
env:
AUTH0_DOMAIN: ${{ secrets.AUTH0_DOMAIN_STAGING }}
AUTH0_CLIENT_ID: ${{ secrets.AUTH0_CLIENT_ID_STAGING_SERVICE_A }}
run: |
docker build
--build-arg AUTH0_DOMAIN=$AUTH0_DOMAIN
--build-arg AUTH0_CLIENT_ID=$AUTH0_CLIENT_ID
-t ${{ steps.meta.outputs.tags }} .
```

Key learnings:
* **Secret Rotation:** Each microservice requires its own Auth0 Machine-to-Machine application for fine-grained API permissions. Rotating these credentials across all services' CI/CD variables is a operational overhead.
* **Local Development:** We use a dedicated Auth0 tenant for development. Engineers must pre-configure callback URLs for their local instances, which can be a friction point.
* **Deployment Strategy:** Blue-green deployments require the new environment to be added to the "Allowed Callback URLs" in the Auth0 dashboard *before* cutover, adding a manual step or requiring automation via Auth0's Management API.

The mono-repo structure helped us keep the Auth0 integration library in sync, but it meant that any change to the auth library triggered a full pipeline run for all dependent services. We mitigated this with path filters in our CI config.

I'm curious how others have automated the synchronization of Auth0 tenant rules, custom databases, or social connection settings across multiple environments (dev/staging/prod). Is anyone using Terraform or the Auth0 Deploy CLI in their pipelines, and how do you handle the state drift?

--crusader


Commit early, deploy often, but always rollback-ready.


   
Quote
(@cloud_ops_learner_99)
Estimable Member
Joined: 1 month ago
Posts: 137
 

That's a smart approach with the shared auth library. I've been trying to set up something similar but for AWS services in a mono-repo. Did you run into any issues with different microservices needing slightly different token validation rules? I'm worried about our "user-service" needing a few extra claims that our "api-gateway" doesn't, and if that would break the shared library pattern.

Also, curious how you handle the build-args in the Dockerfile itself. Do you just `ARG` them and then `ENV`? I always get nervous about layer caching with secrets like that, even as build-args.



   
ReplyQuote