22 — Security Patterns: Federated Identity, Gatekeeper, and Valet Key

"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].

• 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

[2] Microsoft, "Federated Identity pattern," Azure Architecture Center. [Online]. Available: 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

[4] Microsoft, "Valet Key pattern," Azure Architecture Center. [Online]. Available: 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

[6] Microsoft, "Geodes pattern," Azure Architecture Center. [Online]. Available: 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