Cloudflare OIDC Provider
You set up a cloudflare oidc provider by linking your identity service to Cloudflare through standard OpenID Connect endpoints. This setup lets your team log in to private apps using one central identity. Most teams map group names from the identity service to access rules inside Cloudflare. Still, broad group roles often give users full entry to back-end systems with no limits on their actions. How a cloudflare oidc provider works OpenID Connect is an identity check built on top of the OAuth
K8s OIDC Authentication + K8s Encryption Provider Config: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a cloudflare oidc provider by linking your identity service to Cloudflare through standard OpenID Connect endpoints. This setup lets your team log in to private apps using one central identity. Most teams map group names from the identity service to access rules inside Cloudflare. Still, broad group roles often give users full entry to back-end systems with no limits on their actions.
How a cloudflare oidc provider works
OpenID Connect is an identity check built on top of the OAuth protocol. When you set up a cloudflare oidc provider, two systems exchange trust details. You register a new app inside your main identity directory first. That directory gives you a client ID, a client secret, and discovery URLs.
Next, you add those details into the Cloudflare dashboard as a login method. You also copy a callback URL from Cloudflare back to your identity service. This callback URL tells the identity service where to send users after they log in.
When an engineer tries to open a protected tool, Cloudflare stops the request. It sends the engineer to your identity service to sign in. The identity service checks the user password and any multi-factor prompts. Once the user passes, the service sends an authorization code back to the callback URL.
Cloudflare trades this code for an ID token signed by the identity provider. The token holds basic user facts like an email address and group names. Cloudflare reads these claims and checks them against your team rules. If the email and group match the rule, the user enters the app.
Why login checks leave gaps inside databases and shells
A cloudflare oidc provider does a great job of checking who sits at the keyboard. It stops strangers at the edge before they reach your network. It also lets you turn off a user account in one place when someone leaves the team. For simple web apps, this edge check is often enough.
The gap appears when engineers connect to databases, servers, or cloud consoles. An OIDC check happens only at the start of a session. Once the login rule passes, the user gets an open path to the target system. The login service does not read the SQL queries or shell commands that run next.
K8s OIDC Authentication + K8s Encryption Provider Config: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Inside the database or server, engineers often share a few broad service accounts. Everybody in an engineering group might land in the same admin database role. One bad command can still drop a table or pull raw customer records. The identity log shows that the user logged in, not what they ran.
What to review before you roll out group rules
Before you turn on OIDC rules for production tools, check what claims your provider sends. Not every identity tool sends group names in the basic token by default. You may need to add a group scope so Cloudflare can read team memberships. Keep your group list clean and tied to real job tasks.
You should also check how long your login tokens last. A long token lifetime means a user stays logged in for days without a fresh check. Even if you remove a user from a group, an active session might keeps the session active. Set short token lifetimes for any rule that guards production data.
Finally, remember that edge login rules only solve the front door problem. To protect real data, you must control individual queries and mask sensitive fields like emails or card numbers in results.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What details do I need to add an OIDC provider in Cloudflare?
You need a client ID and a client secret from your identity service. You also need the authorization URL, token URL, and key URL from the provider.
Can I pass group claims through a cloudflare oidc provider?
Yes, you can pass group claims if your identity service includes them in the ID token. You then write rules that match those group names to grant entry.
Does OIDC control what queries an engineer runs after logging in?
No, OIDC only checks identity when the user signs in at the start. It cannot inspect, block, or mask database queries or shell commands during the session.