Pocket Id Caddy
A pocket id caddy setup pairs an OIDC provider with a web server for passkey login. You point the web server to your identity app so users sign in before reaching tools. Platform teams use this pattern to protect internal dashboards and self-hosted web apps. They replace shared passwords with hardware keys or phone prompts. Still, once a user signs in, the web server often grants broad app permissions. A single login might expose admin pages, database tools, and sensitive records all at once.
Microsoft Entra ID (Azure AD): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A pocket id caddy setup pairs an OIDC provider with a web server for passkey login. You point the web server to your identity app so users sign in before reaching tools. Platform teams use this pattern to protect internal dashboards and self-hosted web apps. They replace shared passwords with hardware keys or phone prompts. Still, once a user signs in, the web server often grants broad app permissions. A single login might expose admin pages, database tools, and sensitive records all at once.
How a pocket id caddy setup works in practice
Pocket ID acts as a clean identity provider that supports passkeys and OpenID Connect. It skips passwords and uses WebAuthn so people sign in with biometrics or security keys. Caddy acts as the front-end web server that handles TLS certificates and routes incoming traffic. To link them, you add an auth handler or forward auth rule inside the server. When a user visits a protected web app, the server pauses the initial HTTP request. It checks whether the browser holds a valid session cookie for that domain. If no valid session exists, the server sends the user over to the identity app. The user taps a passkey on their laptop or phone to prove who they are. Then the identity app sends a signed token back to the web server. The server reads the token, checks the user group, and lets the traffic pass through. You also need to pass standard forwarding headers from the web server to the identity app. Without these headers, the identity app cannot read the true client IP or scheme. Teams also create separate client IDs for each internal web app they host. This keeps login scopes clean across different internal services.
What passkey web login solves and what it leaves open
Pairing passkeys with a modern web server fixes several big login headaches for engineering teams. First, it removes weak passwords and shared team logins from your internal web tools. Phishing attacks fail because passkeys bind directly to your specific domain name. Second, the web server automates TLS certificates so login traffic stays encrypted over the network. You get a clean single sign-on flow for internal apps without buying complex enterprise software. Still, this setup only checks who logs in at the front door of the app. Once the web server forwards the traffic, its job is mostly done for that session. It does not inspect the database queries or system commands that run inside those apps. For example, an engineer might log in to a web database client using a passkey. The web server allows the request because the user belongs to the engineering group. Inside that tool, the engineer can still run a broad query that dumps customer tables. The web server also cannot rewrite sensitive fields like emails, phone numbers, or card numbers. Also, web access logs only show HTTP paths rather than the actual commands or queries executed. Teams need finer controls over what actions happen after a user passes the login check.
Best practices for managing internal app permissions
Start by splitting user groups in your identity app by job function and risk level. Do not let every valid passkey holder reach admin panels or production data tools. Next, set short session lifetimes so stolen browser cookies expire before an attacker can use them. Keep your identity app database backed up so you never lose registered user passkeys. Check your web server logs often to spot failed login spikes or strange traffic routes. Finally, pair your web login setup with deeper controls for databases, shells, and cloud APIs. Gateways at the web layer handle browser routing well, while database and command layers need deeper inspection.
Microsoft Entra ID (Azure AD): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Why does my passkey login fail behind a reverse web server?
Passkeys require a valid HTTPS domain and matching host headers to work in the browser. Make sure your web server passes the original host and scheme headers to the identity app.
Can Caddy validate OIDC tokens on its own?
The base web server uses forward auth to check sessions against an external auth helper service. You can also compile the server with third-party security plugins that handle OIDC flows directly.
Does a pocket id caddy setup protect direct database sessions?
No, this pattern only guards HTTP web traffic that passes through the web server. Engineers using desktop database clients or terminal tools bypass the web login screen entirely.