DEV Community: Jessica Temporal

Preview Auth0 Changes Safely with Deploy CLI Dry Run

Jessica Temporal — Tue, 16 Jun 2026 22:25:31 +0000

Managing your Auth0 tenant configuration as code shouldn't be a "guess and check" process. In this video, I'll demonstrate how to use the Auth0 Deploy CLI's Dry Run feature. Learn how to preview exactly which resources will be created, updated, or deleted before you ever touch your production environment.

What You'll Learn

How to configure the Auth0 Deploy CLI with a config.json file.
The proper syntax for exporting your current tenant configuration to YAML.
How to use the --dry-run flag to validate local changes.
Best practices for keeping sensitive credentials out of your Git history.

Resources

📄 Auth0 Deploy CLI Documentation
💻 GitHub Repository

How to Decode, Encode, and Validate JWTs inside Claude Code

Jessica Temporal — Fri, 29 May 2026 17:42:15 +0000

Stop context switching and start debugging. Let me show you how to supercharge your AI agent with JWT Skills. Learn how to decode, encode, and validate JSON Web Tokens (JWTs) directly within your terminal session using Claude Code. Whether you're troubleshooting an expired token or testing a custom claim, these tools bring security insights right into your development flow.

What You'll Learn:

How to install the jwt-skills
Decoding tokens to inspect headers, payloads, and claims.
Identifying security flags like expired tokens or PII in payloads.
Generating test tokens with custom claims for edge-case testing.
Validating tokens against JWKS endpoints for production-level checks.

Resources:

🛠 Get the Skills
📖 JWT Deep Dive

Manage Your Auth0 Tenants Faster with the Gemini CLI Extension

Jessica Temporal — Wed, 29 Apr 2026 21:01:35 +0000

Stop switching between your browser and terminal to manage identity. In this video, I'll show you how to integrate the Auth0 MCP Server directly into your Gemini CLI.

Learn how to leverage AI to query your applications, initialize tenants, and manage APIs using natural language commands without leaving your development environment.

What You'll Learn

How to find the Auth0 extension on the official Gemini page.
The one-command installation process for the Auth0 MCP server.
Authenticating and initializing your Auth0 environment via CLI.
Using natural language to list applications and create new API resources.

Resources

How to Use Auth0 Agent Skills in Claude Code & AI Coding Assistants

Jessica Temporal — Mon, 06 Apr 2026 18:27:59 +0000

Tired of your AI coding assistant hallucinating APIs or writing insecure auth patterns? In this video, I'll show you how to use Auth0 Agent Skills to teach your AI assistant (like Claude Code or GitHub Copilot) how to implement Auth0 correctly. Say goodbye to XSS vulnerabilities and manual JWT decoding—ship production-ready, secure authentication from the start.

What You'll Learn

Why standard AI coding assistants struggle with secure authentication.
How to install Auth0 Agent Skills via NPX or Claude Code plugins.
The difference between Core Skills and SDK Skills (React, Next.js, etc.).
A side-by-side comparison of "hallucinated" code vs. secure Auth0 patterns.
How to implement production-ready auth in Next.js using Agent Skills.

Resources

📝 Read the full blog post
🛠️ Auth0 Documentation
💻 GitHub Repo

Auth0 MCP Server Extension for Gemini CLI

Jessica Temporal — Fri, 27 Mar 2026 11:00:00 +0000

The Auth0 MCP Server is now listed on the official Gemini CLI extensions page. This means the Auth0 MCP Server is now directly installable through Gemini CLI with one command, allowing you to authenticate to Auth0 directly from your Gemini CLI session and load tenant information automatically.

What the Auth0 MCP Server Extension Provides

The extension packages the Auth0 MCP Server for Gemini CLI and adds three integration layers:

Discoverability: Listed on geminicli.com/extensions, searchable by name, installable without manual configuration.

Authentication Commands: Built-in slash commands for Auth0 tenant management:

/auth0:init - Device authorization flow with tenant selection
/auth0:logout - Session termination
/auth0:session - Current authentication status

Context Injection: After authentication, Gemini gains your tenant information so the AI can query applications, APIs, connections, actions, and logs without requiring manual tenant specification in every prompt.

Installation and Setup

Install the extension:

gemini extensions install https://github.com/auth0/auth0-mcp-server

Once the command successfully finishes you should see a message stating Extension “Auth0” installed successfully:

Initialize the Auth0 MCP Server:

/auth0:init

Make sure to allow the command to run when prompted. The server will run automatically.

You'll authenticate via device code flow to select your tenant:

And confirm the permissions:

Once authenticated, you should see a message within Gemini saying the Auth0 MCP Server is configured and to restart Gemini CLI to see the changes:

Refresh the MCP server list with the following command:

/mcp refresh

Gemini now has Auth0 context. Ask: "show me my applications" and the AI will receive the structured information about your applications, which Gemini CLI will display as a structured tool call result:

And since Gemini now understands your tenant structure, existing configurations, and naming conventions, it can also show you the same information in a more readable format:

Why This Matters

Before this extension, using the Auth0 MCP Server with Gemini CLI required manual server configuration, environment variable setup, and custom initialization scripts. The extension collapses that into a single install command and three slash commands.

More importantly: context persistence. Once authenticated, every Gemini session knows your Auth0 environment. You're not re-explaining your tenant structure or copy-pasting app IDs. The AI assistant operates with the same tenant awareness you have.

This is the same Auth0 MCP Server that powers VS Code integrations, now packaged for Gemini CLI's extension model. Same capabilities, different CLI.

What's Next

The Auth0 MCP Server supports tenant management, application configuration, API setup, and log analysis. For implementation details and the full MCP Server feature set, see the list on GitHub here.

The extension is available now at geminicli.com/extensions. Install, authenticate, and start managing Auth0 tenants through natural language.

Demystifying OAuth Security: State vs. Nonce vs. PKCE

Jessica Temporal — Fri, 13 Mar 2026 16:17:44 +0000

Confused by the random strings in your OAuth URLs? You aren't alone. Many developers think state, nonce, and code_challenge (PKCE) are redundant—but skipping just one could leave your users' accounts wide open to attackers like "Eve." In this video, I'll break down why these three parameters are like three different locks on three different doors. We’ll look at real-world attack scenarios and show you exactly how each one keeps your app secure.

💡 What You’ll Learn:

The State Parameter: How to prevent Cross-Site Request Forgery ($CSRF$) attacks.
The Nonce Parameter: Why ID tokens need protection against Replay attacks.
PKCE (Proof Key for Code Exchange): Protecting mobile and single-page apps from Authorization Code Injection.
Implementation Strategy: Why you should use all three instead of picking just one.

🔗 Links:

If you enjoy this content and want to learn more about identity, security, and access management, subscribe to our channel!

Have a topic you'd like to see covered? Let us know if the comments below 👀

Automating CSS versioning in staging through GitHub Actions

Jessica Temporal — Tue, 03 Feb 2026 06:00:00 +0000

While setting up a staging environment in a new hosting platform, I ran into an issue where static assets were aggressively cached with no straightforward way to invalidate them. This made staging deploys unreliable and validating changes slow.

I could have spent hours fighting with cache headers and purge APIs, but there’s a simpler approach. Rather than fighting the cache, I leaned into patterns that avoid invalidation entirely and make staging behaviour explicit and predictable.

The Problem

This staging environment was behaving badly:

Static assets were cached aggressively
Cache purging is unavailable
Deploys appear as “successful” but changes were not visible

So I was stuck with a cache that I couldn’t purge and changes I needed to validate somewhere other than my local machine. So I figured it was time to version the styling scripts.

Versioned static assets

One reliable way to bypass aggressive caching is to change the asset URL on every deploy.

Static assets are referenced with a deploy-specific version, in my case I went for short git SHA.

<link rel="stylesheet" href="/static/css/base.css?v=6ea4bbe">

This was enough to fix the problem:

CDNs cache by URL.
A new URL guarantees a cache miss.
No reliance on purge APIs or cache headers.
Simple, deterministic behaviour.

This approach works well for staging, where correctness matters more than caching efficiency. Then my next challenge was: how to get this into my deployment without me manually editing the URLs every single time?

Label-gated staging deploys

I can’t remember to update URLs manually every single time, so instead of suffering every time my CSS wouldn’t update accordingly, I adjusted my code and added a step in my GitHub Actions to take care of this for me.

Since I’m the sole developer on this project, my staging deploys are explicitly controlled using pull request labels.

A pull request is deployed to staging only when the preview is applied.

GitHub Actions

In case you want to replicate this for yourself, here’s how to do it. The steps are pretty simple:

Run your tests;
If tests pass deploy the app to the staging environment
Make a comment on your PR so you know the version of the CSS that should be live
Enjoy QA-ing your staged deployment

First the setup for your action:

name: Run tests and stage changes

on:
  pull_request:
    types:
      - opened
      - synchronize
      - reopened
      - labeled
      - unlabeled

jobs:
# ...

This names the action and tells it which Pull Requests to look at, in my case all of them.

1. Tests running

I want to make sure that all pull requests pass my test suite, so the first job checks out the pull request, installs the dependencies and creates necessary files, then runs the tests:

# ...

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout PR branch
        uses: actions/checkout@v4

      - name: Install uv
        uses: astral-sh/setup-uv@v7

      - name: Install dependencies
        run: uv sync --extra dev

      - name: Setup test environment
        run: cp .env.example .env

      - name: Run tests
        run: uv run pytest

  deploy-staging:
  # ...

This guarantees code quality in all pull requests before I even consider deployment.

With a successful test we can move on to deployment.

2. Stage the deployment

The deployment job only needs to run when the preview label is included.

Then a neat trick: you can get the SHA for the deployment with github.sha and write it out to a file, in this case .deploy_sha and once the code is sent to the cloud it can use that file to read the information.

jobs:
  test:
    # ...

  deploy-staging:
    # Only run after tests pass
    needs: test
    if: contains(github.event.pull_request.labels.*.name, 'preview')

    runs-on: ubuntu-latest

    permissions:
      contents: read
      pull-requests: write

    steps:
      - name: Checkout PR branch
        uses: actions/checkout@v4

      - name: Install uv
        uses: astral-sh/setup-uv@v7

      - name: Set deploy SHA
        run: echo "$" | cut -c1-7 > .deploy_sha

      - name: Deploy to staging
        env:
          CLOUD_TOKEN: $
          CLOUD_APP_ID: $
        run: # your deploy command here

      # ...

My code also needed to account for that. So first I created a function in my FastAPI app to grab the first few characters of the SHA from either the environment variable or the .deploy_sha file. I also set a fall back to dev.

# Deploy SHA for cache busting - check env var first, then file, fallback to "dev"
def get_deploy_sha():
    """Get deploy SHA from environment or .deploy_sha file."""
    sha = os.getenv("DEPLOY_SHA")
    if sha:
        return sha[:7]

    # Try reading from file (created during CI/CD deploy)
    try:
        with open(".deploy_sha", "r") as f:
            return f.read().strip()
    except FileNotFoundError:
        return "dev"

# Automatically make the deploy_sha available in all templates
templates.env.globals["deploy_sha"] = get_deploy_sha()

The environment variable is used in production which normally doesn’t change unless I see some weird caching I’m not expecting to, whereas while developing locally the fallback takes action and in staging we use the file.

Finally the HTML template looks like this:

<link rel="stylesheet" href="/static/css/base.css?v=">

Since we pass the deploy_sha automatically as part of the globals variables for templates, any page will have the information they need when the application is being built.

3. Get a comment

Finally, I wanted to get a comment I can see both:

That the deployment is live
The hash I should look for in case I notice some discrepancies between what I’m seeing and the deployment

To this I added a final step to the deploy-staging job with the following code:

# ...
jobs:
  test:
    # ...

  deploy-staging:
    # ...
    steps:
      # ...

      - name: Comment staging URL on PR
        uses: actions/github-script@v7
        with:
          script: |
            const sha = '$'.substring(0, 7);
            const marker = '<!-- staging-deploy -->';
            const body = `${marker}\n🚀 **Staging deploy complete** \n\nPreview: $\n\nCommit: \`${sha}\``;

            // Find existing comment
            const { data: comments } = await github.rest.issues.listComments({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
            });

            const existing = comments.find(c => c.body.includes(marker));

            if (existing) {
              await github.rest.issues.updateComment({
                owner: context.repo.owner,
                repo: context.repo.repo,
                comment_id: existing.id,
                body: body,
              });
            } else {
              await github.rest.issues.createComment({
                owner: context.repo.owner,
                repo: context.repo.repo,
                issue_number: context.issue.number,
                body: body,
              });
            }

Since I also didn’t want every new commit to generate a new comment, I used an HTML comment to mark the message:

const marker = '<!-- staging-deploy -->';

Since comments render Markdown the HTML shows up in edit mode but gets hidden when displayed.

And this is what that looks like as the final step of the deploy-staging is completed:

Trade-offs of this approach

This gave me full control over which pull request is staged and my staging represents “currently under review” making it easier for me to even QA the changes myself.

The only downside from this approach is that I can’t have multiple ephemeral per-pull-request environments since I can only make one PR deployment at a time but that works well for my development workflow.

The goal is clarity and control, not maximum automation.

Conclusion

Versioned static assets and label-gated deploys solved my staging cache problem. Now CSS files get a git SHA in the URL, GitHub Actions handles deployments when I apply the preview label, and I always know which version is live. No cache invalidation needed.

AI-powered software development flow: Lessons from shipping My Yarn Stash

Jessica Temporal — Tue, 03 Feb 2026 05:00:00 +0000

When I started building My Yarn Stash, I wasn’t trying to prove AI could build an app for me.

I wanted to answer a practical question:

What actually changes when you treat AI tools as long-term collaborators across planning, implementation, and design?

Not with demos or toy examples, but with a real product that has users, persistent data, billing, authentication, and migrations—all the unglamorous constraints that come with shipping software meant to stick around.

What follows is a breakdown of how AI fit into each phase, where it helped, where it failed, and what I learned or was reminded about tool boundaries by building something real.

The day the AI deleted my database

Early in the project, I asked a coding agent to help with a schema change. It confidently suggested:

rm yarn.db
# Then recreate with new schema

And I let it.

Gone. All the test data I’d been building up. Hours of manual entry to stress-test edge cases. Deleted in a single command because the AI treated the database like a throwaway artifact.

The AI didn’t behave incorrectly. It did exactly what made sense if you assume databases are ephemeral. The problem was that I hadn’t established guardrails.

That moment reminded me to both pay more attention and adjust how I collaborated with AI tools. I needed to be very clear about constraints.

Later I added rules to my copilot instructions:

NEVER delete database files
ALWAYS run migrations instead
Before any destructive operation, run backups first

And went on to recreate my database. The AI didn’t change its behaviour. I changed mine.

This became the pattern for the entire project: AI amplified my clarity and punished my ambiguity and lack of attention.

The database deletion reminded me of something fundamental: vague instructions produce unpredictable results. That lesson shaped how I approached every other phase of this project moving forward.

Separate conversations, separate contexts

After the database incident, I knew I needed better constraint management. That started with how I structured conversations.

I treated ChatGPT like a colleague I’d grab for specific discussions.

Each feature got its own conversation thread:

One for billing and entitlements
One for the AI extraction flow
One for soft-delete patterns
One for launch strategy

This wasn’t about organization. It was about context management.

When everything lives in one chat, the AI starts to get slow and confused, that’s when constant “summarizing history” increase time to answers, so as an engineer leveraging AI, you have to dutifully manage the context window. A billing conversation shouldn’t bleed into UI discussions. Implementation details shouldn’t pollute planning threads.

Separate chats forced clarity. Each conversation had a single purpose, which made it easier to:

Stay focused on one problem
Evaluate outputs against specific goals
Make decisions without noise

What those conversations actually looked like

Branding: From vague to concrete

I started with “I want it to feel cozy and calm.” Through discussion, we identified edge cases I hadn’t considered:

Text baked into images would need rework every time pricing changed
Realistic imagery would read as generic stock photos
“Organizing” visuals imply judgment. Better to frame as “inventory tracking”
Gradients applied inconsistently would create visual noise

The conversation forced specificity. By the end, I had constraints like “no text in images” and “single vertical gradient system” that my coding agent could implement reliably.

Account page: Surfacing failure modes

When planning the account page, ChatGPT helped identify non-obvious problems:

Timezone drift : Automatically updating timezone when users travel would silently change project dates. Solution: only update on explicit user action.
Empty state guilt : Showing “0 finished projects” or prompting users to “finish your first project” creates pressure. Solution: gentle empty state with no call to action.

These weren’t implementation details. They were experience risks that would erode trust if missed.

Launch strategy: Reframing the goal

I initially thought about launch as a visibility event: where to post, how to announce.

The discussion reframed it as a state change : from “only I use this” to “other people can use this safely.”

That shifted focus from:

“How many people see this?”

To:

“What breaks when the first real users arrive?”
“Is this experience internally consistent?”
“Where can people get confused or succeed quickly?”

I deprioritized announcements and spent more time on onboarding clarity instead.

Every useful insight got distilled into markdown. Feature specs, constraints, architectural decisions: all rewritten in my own words with the help of ChatGPT, structured for clarity, stored alongside the code.

This forced two things:

I had to actually understand the decision
The output became durable and reviewable

Stack decisions: What I chose vs. what I asked about

With clear conversation boundaries established, I could make better stack decisions. I came into the project with strong opinions about some parts of the stack and no opinion at all about others.

What I decided before asking AI:

Auth0 for authentication (familiar, reliable, scalable)
FastAPI as the web framework (Python, async, good docs, also familiar and with great Auth0 support)
Supabase for database and storage (Postgres with good tooling and prod database at 0 cost)
Vanilla JavaScript and handwritten CSS to start instead of a framework (less abstraction, easier to reason about with AI and for me to follow along)
Resend for emailing users: a welcome email for the users and another to notify myself when new user signed up
Replicate: to provide AI features like the label extraction information

These choices weren’t about AI compatibility. They were about reducing cognitive load and keeping a codebase I could jump in without the help of AI if needed.

What I asked AI to help evaluate:

Payment gateway : I had no strong opinion. We discussed options and landed on Polar for simplicity and developer experience.
Deployment platform : I wanted something low-cost that I already understood. Heroku fit both criteria.

The pattern here matters: I brought constraints and context to the conversation instead of asking “what should I use?” in a vacuum.

AI didn’t tell me what to build with. It helped me think through trade-offs for the decisions I hadn’t made yet.

Learning which model does what well

Stack decisions settled, the next challenge was figuring out which AI tool to use when. Understanding model strengths came from repeated experience across different contexts.

I didn’t use one AI tool for everything. That was deliberate. Through building, I found a flow that worked for me:

ChatGPT for planning and exploration

Most planning conversations happened in ChatGPT in the mobile app. I used it on my phone during downtime to think through features, identify edge cases, and explore design decisions before writing any code.

The mobile accessibility mattered. I could sketch out billing logic while having my coffee in the morning or map out future features during a commute. By the time I grabbed my computer to code, I’d already worked through the conceptual problems.

GitHub Copilot Agents for straightforward work

Well-defined low-complexity features and bugs went to GitHub issues and I would let Copilot handle implementation through PRs asynchronously by assigning Copilot to a given issue. It freed me up to work on more-complex and high value things while Copilot handled the implementation of the “no-brainer” tasks.

When agents got stuck online, I’d download the code and ask Claude Opus to step in.

VS Code Copilot for local development

I used VS Code with Copilot in different modes and with models depending on the work:

Claude Haiku:

Mostly in Plan mode;
Quick iterations when following up on features locally;
Good for refactoring and adjusting implementation details that didn’t require more scope other than one file

Claude Opus:

Mostly in Agent mode;
Complex situations with many moving pieces
Used when precision and accuracy mattered more than speed

No matter the model though, they were always constrained by explicit conventions in copilot-instructions.md. The lesson wasn’t “use the best model.” It was knowing not only when to switch models and modes but also why switching should happen.

That judgment is a skill. AI tools don’t remove it.

The database deletion happened because I let my guard down. I got comfortable with AI-assisted coding and stopped questioning the suggestions. It was a good reminder that different contexts need different constraints. By this phase of the project, I’d learned to match tool capabilities to task requirements.

Functional first, pretty later (because I’m not a designer)

With implementation flowing more smoothly, I turned to design. This required a different kind of clarity.

I deliberately delayed visual design work. Not because of anything AI-related, but because CSS and JavaScript are not my strong suit.

I focused on making things functional first: flows, data models, interactions. Once those settled, I could tackle design from a more stable foundation. It didn’t look ugly but it clearly wasn’t beautiful:

My first exploration with Stitch, Google’s Gemini-based tool that transforms text descriptions into UI designs, showed me how powerful it was. I dropped the link of the working app and asked for a redesign. It made something pretty, but it didn’t look like my product.

So I used ChatGPT to put together the branding guidelines: tone, colour direction, what feelings I wanted the UI to convey. Once I had that document written down, I went back to Stitch with:

Screenshots of the functional app
The branding document
Specific constraints like “redesign this following the brand guidelines”

The result you see below:

That combination worked. The design felt right because I’d done the thinking first. And did I mention it now supports dark mode as well?

The lesson: Tools work better when you’ve already established intent. Just like the database needed constraints, design tools needed direction.

What this experience taught me about building with AI

Going through all these steps I noticed a few patterns that go beyond individual tool choices. These are a few things I’m carrying forward:

1. AI doesn’t replace judgment. It makes judgment more important

The database deletion wasn’t an AI failure. It was a clarity failure. Once I added explicit constraints, the tools became more reliable.

2. Context boundaries matter

Separate conversations for separate concerns reduced drift and forced focus.

3. Model switching is a learned skill

Understanding when to use a lightweight model versus a heavy one came from repeated friction, not documentation.

4. Design still requires taste

AI can accelerate iteration, but you need to know what you’re aiming for. “Make it pretty” produces generic results. “Make it feel cozy and trustworthy” with examples gives you something to evaluate.

5. Shipping something real teaches more than demos ever could

Most AI tool examples live in a world where you can always start over. Production software doesn’t. That constraint forced honesty about where AI helps and where it doesn’t.

What this means for learning AI tools

I always believed developers do better when they learn the limitations of the tools they use when building software. Specially since development is no-longer my day job, this project became an outlet for experiment and trying new tools and it helped shape how I evaluate and talk about AI tools.

Demos have their place in my world, but nothing beats the actual experience of building something and learn by doing.

Building My Yarn Stash gave me a even clearer sense of where AI accelerates work and where it introduces risk. Not from reading about it, but from hitting the boundaries myself.

If you’re trying to find your footing with AI tools: build something real. Solve a problem you face often, try the new tools and find the flow that works for you.

Step away for a moment from the tutorials and courses and build your own project free of the constraints instructors purposely impose in order to teach and give students a good experience. Something with users, data you can’t lose, and decisions that compound over time.

You’ll learn more from one broken migration than from a hundred perfect prompts.

Auth0 for AI Agents is now generally available!

Jessica Temporal — Mon, 24 Nov 2025 16:32:18 +0000

Hey DEV Community! 👋

If you're building AI agents right now (and honestly, who isn't?), you've probably hit the auth problem. You know the one - where the quickest path to getting your agent working is to just hardcode some API keys and move on. It works great... until you need to actually ship to production.

Today, we're excited to share that Auth0 for AI Agents is now generally available, and it's designed to solve exactly this problem.

Auth0 for AI Agents

The Problem with Hardcoded Credentials

Let's be real: when you're prototyping an AI agent with LangChain or LlamaIndex, hardcoded credentials are the path of least resistance. Your agent needs to access Slack, GitHub, Google Calendar, or your own APIs, and frameworks make it easy to just plug in those keys.

But production is a different story:

What happens when your agent needs to act on behalf of different users with different permissions?
How do you handle token refreshing across 30+ different apps?
How do you let users approve critical actions (like making purchases) without giving your agent carte blanche?
How do you ensure your RAG-powered agent only accesses documents the user actually has permission to see?

These aren't edge cases - they're fundamental requirements for any AI agent that's going to interact with real user data and take real actions.

What We Built

Auth0 for AI Agents gives you four key capabilities:

1. User Authentication

Secure and scalable User Authentication allows you to identify who's talking to your agent and give it secure access to your first-party APIs. Your agent can access user-specific data like order history, preferences, or chat logs - all scoped to the right permissions.

2. Token Vault

Token Vault handles OAuth flows with 30+ pre-integrated apps (GitHub, Slack, Google Workspace, and more) plus any custom OAuth provider you want to connect. It manages access tokens, refresh tokens, and the whole lifecycle automatically. Your agent requests a connection, the user authorizes once, and you never have to think about token management again.

The SDK detects when a tool call needs authentication, pauses execution, prompts the user to authenticate, stores the token securely, and resumes automatically. On subsequent calls, it just works.

3. Asynchronous Authorization

Your agent can work in the background and only interrupt the user when it needs approval for critical actions. Using Client-Initiated Backchannel Authentication (CIBA), you can send approval requests via email or Auth0 Guardian (SMS coming soon).

4. FGA for RAG

When your agent uses Retrieval Augmented Generation to search through documents, it needs to respect access controls. Fine-Grained Authorization for RAG ensures that users only get answers from documents they actually have permission to access.

Why This Matters

AI agents are moving from demos to production. The difference between a hackathon project and a real product often comes down to handling auth correctly. We built Auth0 for AI Agents because we kept hearing from developers that this was the hard part - not the LLM integration, not the prompt engineering, but the secure, user-scoped access to real systems.

This isn't about adding features. It's about removing blockers so you can ship production-ready AI agents without building your own auth infrastructure from scratch.

Framework Support

We've built SDKs for the frameworks you're already using:

LangChain (Python & JavaScript)
LlamaIndex (Python & JavaScript)
Cloudflare AI
Firebase Genkit
Vercel AI SDK

Each SDK handles the OAuth dance automatically, so you can focus on building your agent's capabilities, not wrestling with authentication flows.

Get Started

Our free tier includes two connected apps in Token Vault, async authorization, and all the core features you need to start building. As you scale, we have self-service plans that grow with you.

Early-stage startups can apply for one year of Auth0 free.

Start Building Today

Field Notes: Hacktoberfest 2025, Week 5

Jessica Temporal — Sat, 15 Nov 2025 05:00:00 +0000

After GitHub Universe, recovering from a nasty cold, and a lot of work, I know I’m a bit late but here it goes: Final week of Hacktoberfest 2025 report!

GitFichas

After the “big slow down”, we actually saw some more engagement by the community with 5 pull requests in Hacktoberfest’s last week:

5 PRs by the community
- 3 merged
- 2 open

I, on the other hand, got Copilot to work on a few issues 👀: 35 pull requests by AI, all merged. This meant great progress was made and that huge bump in the last days of October in the burn up chart below.

The gap between closed and open issues is still there. I still plan to finish migrating the hand-drawn cards to mermaid before the end of the year but I also want to reach the 100 cards published number, let’s see how it goes.

Here’s the distribution of pull requests worked on in the last week of Hacktoberfest:

Looking at the pull requests for the whole month of October, you can see that shift between a lot of translation pull requests in the beginning of the month to more migrations at the end of October in the chart below:

As far as issues go, the distribution is similar. Some PRs closed more than one issue and some PRs had no issues attached to them, so the numbers vary a bit between merged PRs and closed issues, but the distribution is similar on both:

Other projects

I went back to those PRs I left hanging and worked on them. And now I’m off to work on other stuff, especially some content I want to work on through the end of this year beginning of next one.

With this report we close a successful Hacktoberfest 2025. I was not expecting so many people interested in contributing to GitFichas, and I was very happy to review every pull request that came through.

I hope the folks contributing also had an amazing time as I did.

Happy hacking and see you next year 🎃

Hacktoberfest 2025: Diário de Campo, Semana 5

Jessica Temporal — Sat, 15 Nov 2025 04:00:00 +0000

Depois do GitHub Universe, de me recuperar de uma gripe horrível, e de muito trabalho, eu sei que estou meio atrasada mas aqui vai: relatório da última semana da Hacktoberfest 2025!

GitFichas

Depois da “grande desaceleração”, a comunidade voltou a se engajar mais com 5 pull requests na última semana da Hacktoberfest:

5 PRs da comunidade
- 3 mergeados
- 2 abertos

Já eu, consegui colocar o Copilot pra trabalhar em algumas issues 👀: 35 pull requests feitos por IA, todos mergeados. Isso resultou num progresso incrível e naquele grande pico no final de outubro que você vê no gráfico burnup abaixo.

A diferença entre issues fechadas e abertas ainda continua lá. Minha meta ainda é terminar de migrar as fichas desenhadas à mão para mermaid antes do final do ano, mas também quero chegar nas 100 fichas publicadas, vamos ver o que vai dar.

Assim ficou a distribuição dos pull requests na última semana da Hacktoberfest:

Olhando pro mês de outubro como um todo, dá pra ver bem aquela mudança de foco: no começo do mês rolaram muitos pull requests de tradução, e no final foram mais migrações, como mostra o gráfico abaixo:

Sobre as issues, o padrão é parecido. Alguns PRs resolveram várias issues de uma vez e outros não estavam associados a nenhuma issue específica, então os números ficaram um pouco diferentes entre PRs mergeados e issues fechadas, mas a tendência geral é a mesma:

Outros projetos

Voltei naqueles PRs que tinha deixado pra lá e consegui finalizar eles. Agora vou focar em outras coisas, principalmente uns conteúdos que quero terminar durante o final desse ano e começo do ano novo.

E com esse relatório a gente encerra uma Hacktoberfest 2025 na minha opinião super bem-sucedida. Não imaginava que tanta gente ia se interessar em contribuir pro GitFichas, e adorei revisar cada pull request que apareceu por lá.

Espero que quem contribuiu também tenha curtido esse momento tanto quanto eu.

Espero te ver ano que vem para Hacktoberfest 2026 🎃

Field Notes: Hacktoberfest 2025, Week 4

Jessica Temporal — Mon, 27 Oct 2025 04:00:00 +0000

We are so close to the end of Hacktoberfest I can almost smell it. With one week left to go let’s take a look into how last week went.

GitFichas

After the “big slow down”, this week continued the trend of lower amount of pull requests received with only 8 pull requests for last week:

8 PRs by the community
- 7 merged
- 1 closed

I didn’t make any pull requests to GitFichas as I was working on a big pull request for work I’ll love to share on next week’s report.

On other news, this weekend was the first time that GitFichas had no PRs open since the beginning of Hacktoberfest and to be honest this worked out great for me as I was spending most of my Saturday preparing to travel to GitHub Universe.

The gap between closed and open issues is still there, from my side, since my plan is to finish migrating the hand-drawn cards to mermaid before the end of the year, I plan to start tackling some of the open migration issues with the help of Copilot:

Migrate all English 🇺🇸 cards to Mermaid: 27 issues to go
Migrate all Portuguese 🇧🇷 cards to mermaid: 36 issues to go

Contributor Badges

Hacktoberfest is not over yet! You can still make your contributions and earn at least the 4 of the 6 badge levels:

level 0 is for registering to Hacktoberfest
levels 1 through 4 are for making the 4 pull requests while contributing to open source
level 5 is the supercontributor badge you get while completing 6 pull requests.

I also got the Plant a tree and 1 Badge Club , the first is for the tree planted when you get the shirt for completing 6 PRs, and the second is for anyone that has gotten a Hacktoberfest badge since 2022:

|

Plant a tree |

1 Badge Club |

I know this was a short one but that’s a wrap for week 4! See you soon for the final report on Hacktoberfest 2025. 🎃