Cloudflare Access and Sentry: One Less Login to Worry About

Cloudflare Access, part of Cloudflare for Teams, replaces legacy VPN setups by routing authentication through Cloudflare’s global network. Instead of backhauling traffic to a central appliance, teams log in from any device using their existing identity provider. Now, Cloudflare has open sourced a plugin that extends that experience to Sentry, the widely used error-tracking and diagnostics platform.

The plugin is available on GitHub at cloudflare/cloudflare-access-for-sentry. It addresses a gap in the flow for self-hosted Sentry deployments: once Access verifies a user at the edge, that user still has to log in again to Sentry itself. The plugin eliminates that second login by reusing the JSON Web Token (JWT) that Access already issued.

Why Sentry Still Needed a Login Fix

Sentry helps engineering teams track application errors, roll up related issues, and monitor release health. Cloudflare uses it internally for dashboard errors and product diagnostics. Sentry is offered as a SaaS product and a self-hosted edition that teams run in their own infrastructure or cloud environment.

Self-hosted Sentry raises the familiar question: how do you let remote employees reach the app securely? The traditional answer—a corporate VPN—brings its own problems. Users juggle separate VPN credentials, client software breaks on BYOD laptops and phones, and the underlying appliance has fixed capacity limits that require constant monitoring. Cloudflare Access sidesteps the appliance bottleneck by validating users at Cloudflare’s edge and redirecting them to the origin only when they're authorized.

The remaining friction was Sentry’s own login form. Even with Access in front, users still needed separate application credentials. That’s the step the new plugin removes.

Reusing the JWT

When a user hits an Access-protected application, the identity provider authenticates the user and Cloudflare signs a JWT. That token is stored in the browser and sent with each request to the app. Cloudflare validates the token at the edge before forwarding the request.

A JWT is made of three Base64-URL strings—a header, a payload, and a signature—that work together like this:

  • The header defines the cryptographic operation used to protect the data.
  • The payload holds name-value pairs, usually including the user's identity.
  • The signature lets the receiving party verify the payload is authentic.

The token stores the user identity (typically an email from the identity provider), the authentication domain (something like example.cloudflareaccess.com), the audience (the application’s domain), and an expiration timestamp.

When Sentry sits behind Access, the new plugin picks up that same JWT instead of asking the visitor to authenticate again. It parses the user identity from the token, matches it against the Sentry user directory, and maps the token to the corresponding Sentry profile and permissions. The handoff happens in milliseconds and is transparent to the end user—one SSO login covers both layers.

A Pattern for Other Apps

JWTs keep the integration work simple. An application only needs to support the JWT standard rather than deal with SAML, OIDC, OAUTH, or other protocol variations. The token is also compact and JSON-based, so targets can parse the payload without much ceremony.

Some products, like Redash, already provide native JWT authentication. The Sentry plugin joins Cloudflare’s Atlassian plugin as both a working integration and a reference implementation for other tools. Teams looking to add JWT auth to legacy systems can also follow Auth0’s published guide on the topic.

Cloudflare Access is available on every Cloudflare account, with five free seats included. Setup instructions are available at developers.cloudflare.com/access. Smaller organizations can sign up through Cloudflare’s small business program.