--- title: "22 — Security Patterns: Federated Identity, Gatekeeper, and Valet Key" uid: security tags: ["valet-key", "security", "federated-identity", "roadmap:system-design", "gatekeeper", "system-design"] excerpt: "Security provides confidentiality, integrity, and availability assurances — and the cloud patterns (federated identity, gatekeeper, valet key) enforce them structurally, without baking security into every line of code." date: 2026-08-13T03:27:30+0000 source: https://www.aveshina.my.id/en/blog/security --- "Use HTTPS and hash passwords" was my security plan, and it covered the floor while missing the architecture. Writing it down gave the field a structure: **security provides confidentiality, integrity, and availability assurances against malicious attacks, and the cloud security patterns are structural ways to enforce those assurances without baking security into every line of application code.** [1] The three patterns the roadmap highlights — federated identity, gatekeeper, and valet key — each move a security decision out of the application and into the architecture. The framing that landed is that security at scale is not a feature you add; it is a set of boundaries you draw. Losing the confidentiality/integrity/availability assurances can hurt operations, revenue, and reputation [1], and maintaining security requires both hygiene (well-established practices) and vigilance (detecting and remediating vulnerabilities and active attacks). The patterns below are the structural part of that hygiene — they make the safe path the default path, so individual application code does not have to carry the full security load. ## The three patterns Each pattern addresses a different security boundary: who is the user, what reaches the application, and how does the client touch storage [1]. ```figure ``` - **Federated identity** delegates authentication to an external identity provider [2]. Instead of the application implementing (and securing) its own username/password store, it trusts tokens issued by a dedicated identity provider. This simplifies development, minimizes the requirement for user administration, and improves the user experience (single sign-on). The application's only job is to validate the token it receives — it never touches the credentials. This is how "Sign in with Google" works, and it is the same pattern the ave-space portfolio uses for Supabase Auth. - **Gatekeeper** protects applications and services using a dedicated host instance that acts as a broker between clients and the application [3]. The gatekeeper validates and sanitizes requests, then forwards them to the trusted application node. It provides an additional layer of security and limits the system's attack surface — the application node is never directly exposed, and the gatekeeper can be hardened and audited independently. The trusted node sits in a network zone the public cannot reach. - **Valet key** uses a token that gives clients restricted, direct access to a specific resource, to offload data transfer from the application [4]. Particularly useful with cloud-hosted storage or queues, it minimizes cost and maximizes scalability and performance. The application mints a short-lived token that grants, say, upload rights to one blob for ten minutes; the client uploads directly to storage without the bytes ever passing through the application. The analogy is a hotel valet key — it opens one door for a limited purpose, not the whole building. ## What each pattern buys, and what it costs The three patterns share a common move: they pull a security concern _out_ of the application code and into a dedicated structure (an identity provider, a broker host, a token issuer). The payoff is that the application does less security-sensitive work, which means less surface area to get wrong. The cost is operational — another component to run, another contract to honor (the token format, the validation rules, the token's lifetime). - Federated identity removes password storage from the application (the highest-risk data to hold) at the cost of a dependency on the identity provider. - The gatekeeper removes direct exposure of the application at the cost of an extra network hop and a second component to operate. - The valet key removes the application from the data path at the cost of implementing token minting and expiry logic. ## How I use this The habit is to ask, for each security-sensitive interaction, whether the application _needs_ to be in the path. For authentication, it almost never does — I delegate to a federated identity provider (Supabase/Auth0/Google) and validate tokens, rather than holding credentials. For public-facing services, I put a gatekeeper (or API gateway acting as one) in front so the application is not directly exposed and requests are sanitized before they reach it. For large uploads/downloads, I issue short-lived valet-key tokens so the client talks to storage directly and the application is not a bottleneck for bytes it does not need to inspect. The discipline is to make the safe path the structural default, so that individual developers cannot accidentally ship an insecure path by forgetting a check — the architecture enforces the boundary regardless. ## References [1] Microsoft, "Security patterns," Azure Architecture Framework. [Online]. Available: [https://learn.microsoft.com/en-us/azure/architecture/framework/security/security-patterns](https://learn.microsoft.com/en-us/azure/architecture/framework/security/security-patterns) [2] Microsoft, "Federated Identity pattern," Azure Architecture Center. [Online]. Available: [https://learn.microsoft.com/en-us/azure/architecture/patterns/federated-identity](https://learn.microsoft.com/en-us/azure/architecture/patterns/federated-identity) [3] Microsoft, "Gatekeeper pattern," Azure Architecture Center. [Online]. Available: [https://learn.microsoft.com/en-us/azure/architecture/patterns/gatekeeper](https://learn.microsoft.com/en-us/azure/architecture/patterns/gatekeeper) [4] Microsoft, "Valet Key pattern," Azure Architecture Center. [Online]. Available: [https://learn.microsoft.com/en-us/azure/architecture/patterns/valet-key](https://learn.microsoft.com/en-us/azure/architecture/patterns/valet-key) [5] Microsoft, "Deployment Stamps pattern," Azure Architecture Center. [Online]. Available: [https://learn.microsoft.com/en-us/azure/architecture/patterns/deployment-stamp](https://learn.microsoft.com/en-us/azure/architecture/patterns/deployment-stamp) [6] Microsoft, "Geodes pattern," Azure Architecture Center. [Online]. Available: [https://learn.microsoft.com/en-us/azure/architecture/patterns/geodes](https://learn.microsoft.com/en-us/azure/architecture/patterns/geodes) [7] Microsoft, "Health Endpoint Monitoring pattern," Azure Architecture Center. [Online]. Available: [https://learn.microsoft.com/en-us/azure/architecture/patterns/health-endpoint-monitoring](https://learn.microsoft.com/en-us/azure/architecture/patterns/health-endpoint-monitoring) ```quiz Q: Federated identity delegates ____ to an external identity provider. - authorization (what the user can do) - authentication (who the user is) correct: 1 explain: Federated identity delegates authentication. The application validates the token it receives and never handles credentials directly, simplifying development and improving security. Q: The Gatekeeper pattern's main benefit is… - it speeds up request handling by caching - the trusted application node is never directly exposed; requests are validated/sanitized by a broker first correct: 1 explain: The gatekeeper is a broker host that validates and sanitizes requests before forwarding them to a trusted node that the public cannot reach, limiting the attack surface. Q: A valet key is best described as… - a permanent admin credential stored on the client - a short-lived, restricted token granting a client direct access to one specific resource correct: 1 explain: Like a hotel valet key, it opens one door for a limited purpose. The application mints a short-lived token so the client can reach storage directly without routing bytes through the app. Q: The common move underlying all three patterns is… - baking security into every line of application code - pulling a security concern out of the application into a dedicated structure (IdP, broker, token issuer) correct: 1 explain: Each pattern moves a security-sensitive concern out of the application and into a dedicated component, shrinking the app's attack surface and making the safe path the default. ```