Updating OWASP’s Microservice Security Cheat Sheet: Practical Considerations & Recommendations

Dieser Blogpost ist Teil einer Reihe.

• Teil 1: What’s Wrong with the Current OWASP Microservice Security Cheat Sheet?
• Teil 2: Updating OWASP’s Microservice Security Cheat Sheet: Core Concepts
• Teil 3: Updating OWASP’s Microservice Security Cheat Sheet: Authentication Patterns
• Teil 4: Updating OWASP’s Microservice Security Cheat Sheet: Identity Propagation Patterns
• Teil 5: Updating OWASP’s Microservice Security Cheat Sheet: Authorization Patterns
• Teil 6: Updating OWASP’s Microservice Security Cheat Sheet: Decision Dimensions for Authorization Patterns
• Teil 7: Updating OWASP’s Microservice Security Cheat Sheet: Practical Considerations & Recommendations (dieser Blogpost)

In the earlier posts of this series, I’ve walked you through core concepts, explored many different authentication, identity propagation, and authorization patterns, and we even took a few side steps to uncover what else might be relevant. Along the way, I deliberately avoided making concrete recommendations, because I wanted to ensure you had all the information needed to make educated decisions.

Now, as promised, it’s time to put theory into practice. In this last post, I’ll finally derive recommendations from the insights shared so far and provide practical guidance for implementing authorization, identity propagation, and authentication in real-world microservice systems — a kind of «how-to» for everything we’ve discussed. My goal is simple: to equip you with actionable principles you can apply immediately when designing or reviewing your systems.

🙏 And, as always, your feedback is very welcome — on LinkedIn, or in heimdall’s Discord (#off-topic) — to help make these explanations even clearer and more useful for the community.

Authorization Patterns Recommendations

This subsection maps the decision dimensions to the authorization patterns, using the trade-offs of the corresponding patterns as the primary guiding principle. While multiple patterns may technically be applicable in a given context, some introduce security, operational, performance, or maintenance overheads that make them less desirable in practice. The recommendations below aim to balance these concerns, helping to avoid common pitfalls and promote architectural consistency. Deviations may be valid in specific cases, but should be intentional — not accidental.

The diagram above illustrates the recommended patterns based on the given dimensions.

• If the input data locality required for the decision is service-local, Decentralized Service-Level Authorization is ideal — regardless of other dimensions — since the data’s isolated scope avoids all the drawbacks discussed earlier.

• If the input data locality extends beyond Service-Local — i.e., the same data is shared across multiple services — and the output data cardinality is high while using Authorization Filters is not feasible, then Centralized Service-Level Access Control is better suited to the context.

• In all other cases, Modern Edge-Level Authorization tends to offer the best trade-offs.

• Classic Edge-Level Authorization may still be suitable when input data is organization-wide, output cardinality is low, and all relevant data is either pulled by the PDP at request time at request time or pushed to the PDP out-of-band in advance.

Note: Pattern selection is not an isolated decision. The described patterns form a broader pattern language, where one pattern often implies or necessitates the use of another. For instance, selecting Modern Edge-Level Authorization introduces the concept of an «authorization contract», which must be verified within each service. These contracts represent service-local data, and verifying them naturally leads to adopting Decentralized Service-Level Authorization inside the respective services.

Example: The Blog Platform

To illustrate how multiple authorization patterns may compose into a coherent solution, let’s return to the earlier story of Alice and the blog platform.

The system defines two access requirements:

• Listing articles: Every user is allowed to see the list of available articles, including the title, publication date, author, and a short excerpt.
• Reading articles: Access to the full content depends on the user’s subscription level and the number of full articles already read that day.

These requirements map naturally to different authorization patterns:

• For listing articles, the access logic relies solely on local data stored within the article service. Since the input data is entirely service-local, the Decentralized Service-Level Authorization pattern is ideal — no orchestration or coordination with other services is required.
• Reading a full article, however, requires accessing data managed by multiple services: the subscription service (to verify Alice’s plan) and a usage-tracking service (to check her daily quota). Because the input data is not local and the output cardinality is low — the system makes a decision about a single article — Modern Edge-Level Authorization is a better fit. The payload of the «authorization contract» introduced here might, for example, look similar to: { "sub": "0f4a6554-9069-483d-bc8b-86c6943f22f2", "iat": 1757378963, "requested_article": "<uuid>", "allowed_representation": "<full | excerpt>", ... }, which then leads to verifying this contract within the article service using Decentralized Service-Level Authorization.

Example: A Document Management System

Let’s now shift the service landscape slightly to explore the applicability of the remaining patterns. Imagine Alice now wants to access her employer’s document management system.

• Listing documents: Users can only list documents related to the projects, they are a team member of
• Reading documents: Users can only read documents related to the projects, they are a team member of

These map to the following patterns:

• Listing documents requires access to the project members service. Given the typically high output cardinality, Centralized Service-Level Authorization is the best fit.
• While reading a document could use the same pattern, Modern Edge-Level Authorization is a better fit. It simplifies the implementation of the document-rendering service and ensures that all exposed endpoints — not just the document delivery one — are consistently subject to access control.

Last but not least, the performance requirements and input data cardinality strongly influence the PDP choice — PBAC, ReBAC, or NGAC — and integration approach — embedded vs. external. However, this decision may also be shaped by the available tooling for policy and policy input data distribution — which brings us to the next section.

Data and Policy Distribution in Practice

Building on the concepts introduced in Policy Input Data Distribution Strategies and Policy Distribution Strategies, this section demonstrates how the out-of-band data push and out-of-band delivered policies approaches translate into concrete architectures for real-world PDP deployments. These architectures — whether based on embedded PDPs or standalone PDP services — incorporate specific control-plane components to manage initialization, configuration, and runtime updates, ensuring that PDPs remain synchronized and deliver accurate authorization decisions in dynamic environments.

These control plane components are:

• Configuration Repository: Stores the desired configuration for each PDP instance, including detailed references to required policies — such as their repository locations and version information — as well as PIP integration settings, including endpoints, supported protocols, credentials, and other communication-specific parameters.
• Distributor: A control-plane component responsible for distributing configuration that enables Aggregators to obtain and apply data and policy artifacts. It retrieves configuration from the Configuration Repository and monitors it for changes. Whenever an Aggregator connects or updated configuration becomes available, the Distributor pushes the applicable configuration to that Aggregator. Depending on the implementation, it may also act as a relay for data updates from PIPs, forwarding only the relevant updates to each Aggregator based on their configured subscriptions.
• Aggregator: A control-plane component responsible for configuring a PDP instance with the required policies and data. The Aggregator acts as a client of the Distributor, connecting to it to receive its configuration and any updates. Based on this configuration, it retrieves policies and data from designated sources — policy repositories for policies and PIPs for data — and monitors these sources to ensure the PDP remains synchronized with the desired state. Monitoring of policies depends on the capabilities of the policy repository and typically involves polling. For data updates, Aggregators may either pull directly from PIPs or receive change notifications via decoupled mechanisms such as message buses or webhooks. Event-based delivery is often preferred due to its scalability and resilience, but it’s not strictly required.

The following setup illustrates this approach, showing how a PDP can be provisioned with policies and data while supporting runtime updates.

1. The Distributor starts, retrieves configurations from the Configuration Repository, and waits for Aggregator connections.
2. An Aggregator starts, connects to the Distributor, and receives its configuration.
3. The Aggregator pulls policies from the specified Policy Repository.
4. It fetches initial data sets from the designated PIPs.
5. The Aggregator configures the PDP with the retrieved policies and data.
6. When a PEP intercepts a request, it queries the PDP for an authorization decision. If the request is allowed and forwarded to the microservice, it may result in updates to microservice-managed data.
7. Resulting update events are sent to the event distribution system and received by the interested Aggregators.
8. Aggregator updates the PDP’s data sets accordingly.

Similar setups have been successfully adopted in large-scale production environments. For example, Netflix presented a comparable design at KubeCon 2017 (video, slides). Their terminology differs slightly: the component shown as Aggregator in the diagram above is called the «AuthZ Agent», and instead of letting each agent independently collect required data, Netflix introduced a central «Super PIP» (which they call the «Aggregator») positioned between the event distribution system and the agents. This component preprocesses and routes relevant data updates, while the AuthZ Agents remain responsible for configuring and updating the embedded PDP instances.

An open-source project that implements a similar architecture is OPAL - Open Policy Administration Layer, which allows managing OPA and Cedar-Agent instances. Compared to the diagram above, OPAL delegates responsibility for relaying data updates to the Distributor, which pushes relevant changes to each Aggregator instance.

Note: Although both examples above use PBAC PDP engines, the architectural principles described here are not specific to PBAC engines. The control-plane components — configuration repository, distributor, and aggregator — as well as the mechanisms for policy and data provisioning, apply equally to other PDP types, such as ReBAC and NGAC. Unlike PBAC PDPs, which typically store policies and data only in memory, ReBAC and NGAC PDPs maintain persistent storage. In such deployments, the distributor is typically implemented as a CI/CD pipeline to handle automated provisioning and policy updates and does not manage runtime data updates.

This out-of-band data push approach introduces an important challenge: Consider a microservice (e.g., Service A) that updates its own database after a successful request and emits a corresponding domain event intended to notify PDP-related infrastructure (some of the interested Aggregators via an event bus). If the event is lost, delayed, or not processed correctly, the PDP’s internal state may become outdated. As a result, future authorization decisions — possibly in other services — may be based on stale or incomplete data, leading to incorrect access grants or denials.

This situation reflects a classic distributed transaction problem: changes in the microservice and the state change in the PDP must eventually converge, but there’s no atomic commit across both systems. Since traditional distributed transactions are often impractical or undesirable in such architectures, solutions may range from simple reliable event delivery mechanisms, like the Transactional Outbox to more sophisticated patterns like Saga if acknowledgement of event delivery is required.

Policy Input Data Governance

As in the previous section, this section builds on the concepts introduced in Policy Input Data Distribution Strategies, but focuses on challenges common to all strategies that were not addressed earlier:

• Structural and semantic consistency: ensuring that supplied data matches the assumptions encoded in policies, such as the existence of user identifiers, values for resource ownership, etc., as a renaming of a field, change of type, or omission of an attribute may prevent policies from being evaluated correctly, creating the risk of incorrect authorization decisions.
• Consumer visibility and coordination: knowing which policies depend on which attributes so that producers can coordinate safely with policy owners before making schema or semantic changes.

These challenges are inherent to distributed architectures. Whether in Big Data pipelines spanning multiple data sources and transformations, or if multiple microservices are communicating to each other to execute some business function, in both domains, data or messages can break consumers if schemas or semantics change unexpectedly, and accountability for who relies on which data is unclear.

To address this, explicit agreements — often called data contracts in Big Data domain or consumer driven contracts in microservice architectures — codify the shared expectations between producers and consumers and define the «API of data» being exchanged. These types of contracts typically define schema, semantics, and quality guarantees, and also provide mechanisms for coordinated change management.

Adapting the same principles to authorization architectures bring similar benefits:

• Communicating the Data API: Contracts act as a shared reference between PIPs (data producers) and policy authors, clarifying which attributes are required and how they are structured.
• Protecting Consumer Expectations: Contracts can include domain constraints, value ranges, or other guarantees, helping policy assumptions remain valid as data evolves.

That would also ensure that data supplied to PDPs — whether pulled on-demand, pushed out-of-band, or passed inline — is complete, correctly typed, and semantically valid before reaching the PDP.

Standards such as the emerging Open Data Contracts Standard provide structured ways of defining such contracts, while related tooling like the Data Contract CLI supports validation and can also be used for enforcement. Alternatively, open-source governance platforms such as Apache Atlas can be adapted to manage metadata, lineage, and schema evolution, or tools like Pact can serve as a practical step toward implementing such contracts by codifying consumer expectations and validating producer behavior — all helping ensure that exchanged data meets structural and semantic requirements.

Interplay Between Authorization, Authentication, Identity Propagation Patterns, and Zero Trust

Authentication (who you are), authorization (what you’re allowed to do), and identity propagation (how the results of authentication are securely carried forward) each address distinct concerns, yet they are deeply interconnected. The usage of one affects the requirements of the others, and vice versa. And only by aligning them consistently can identity, access, and trust be continuously verified and enforced across the system. As a natural consequence, the system as a whole comes to embody the principles of Zero Trust:

• Never trust by default: Treat every request as untrusted, even inside the same network perimeter.
• Always verify everything: Continuously and adaptively authenticate and authorize all requests, taking real-time signals, like user behavior or device state into account.
• Least privilege: Grant subjects, be it a user, device, or e.g. a service, only the permissions they need, minimizing attack surface.
• Micro-segmentation: Divide networks and systems into isolated micro zones to limit lateral movement.
• Assume breach: Operate as if attackers are already inside - monitor, log, and audit continuously.
• Protect data: Strongly encrypt sensitive information in transit and at rest to ensure confidentiality and integrity.

To achieve this alignment, it helps to determine the authorization approach first, then select identity-propagation mechanisms that can reliably convey attributes about the subject, and only then select the proper authentication patterns. This order prevents earlier decisions from imposing constraints that would undermine a secure, scalable, and maintainable system, while leaving room for deliberate deviations — for example, shifting enforcement closer to a service when downstream identity propagation makes it necessary.

Building on the outcome from the Authorization Patterns Recommendations, the application of this principle leads to the following recommendations:

• Decentralized Service-Level Authorization

  • When a service needs to communicate to downstream services, a stable, canonical representation of the external subject is required so that each hop can evaluate requests consistently. Applying the Protocol-Agnostic Identity Propagation pattern at the edge supports the required issuance of a signed subject structure — a special purpose «Authorization Contract» — which would travel with the request across the call chain.
  • However, this pattern alone does not address all limitations of Decentralized Service-Level Authorization: every downstream endpoint remains accessible to any authenticated subject. Additionally, endpoints intended to be public would now require authentication. Combining this pattern with Modern Edge-Level Authorization configured with a default-deny rule ensures that no endpoint is reachable unless explicitly permitted. Services that need to expose endpoints can now define allow rules: purely public endpoints can bypass authentication and the deny-all rule, while endpoints requiring authentication can disable only the deny-all rule.
  • Endpoints that do not consume the canonical contract (e.g., health checks, actuator APIs) require additional protection to prevent access from malicious peers within the same network. This protection can be provided through either the Kernel-Level Authentication pattern or the Service-Level Proxy-Mediated Authentication pattern, both of which establish workload identity for every inbound connection.
  • For services without downstream dependencies, identity propagation is unnecessary, but maintaining a default-deny posture is still recommended. This can be enforced through the same edge-level patterns or, alternatively, by using Side-Car-Proxy-Based Authorization — a localized form of Modern Edge-Level Authorization — together with Service-Level Proxy-Mediated Authentication to validate the caller and determine its subject for internal processing.

• Centralized Service-Level Authorization: The same approach as for Decentralized Service-Level Authorization applies.

• Modern Edge-Level Authorization:

  • If a service needs to communicate with downstream services, a stable subject representation across hops is required. In this case, it is necessary to deviate from the result of the Authorization Patterns Recommendations and fall back to Centralized Service-Level Authorization. This deviation is valid because adding custom claims to, or changing the canonical subject entirely to build the «Authorization Contract» (the default behavior of Modern Edge-Level Authorization) would break downstream services that rely on it for their own authorization. Using a centralized service-level approach preserves consistency across the call chain while maintaining enforcement, though modern edge-level authorization mechanisms are still used, but limited to the bare minimum.
  • If no downstream calls are needed, the service can make use of Modern Edge-Level Authorization to its full extent, and Edge-Level Authentication is a natural fit to establish the external subject.
  • In either case, pairing with Kernel-Level Authentication or Service-Level Proxy-Mediated Authentication ensures that workload identity is established and inter-service communication — here between the edge and the service — is protected.

• Classic Edge-Level Authorization:

  • Since no service-local data is used, this pattern naturally combines with Edge-Level Authentication and, as with other patterns, should be complemented with Kernel-Level Authentication or Service-Level Proxy-Mediated Authentication.
  • If there is a need to communicate with downstream services, Protocol Agnostic Identity Propagation can be adopted as well.
  • However, as discussed in the Classic Edge-Level Authorization section, this pattern has inherent socio-technical limitations. Therefore, Modern Edge-Level Authorization is recommended instead.

Note: While service-level code-mediated or proxy-mediated authentication are commonly used patterns to validate and establish the external subject, these approaches practically not only restrict secure identity propagation to token exchange-based only, which is actually designed to narrow the authorization scope of a requester in third-party contexts and is not intended for first-party use. They also tightly couple microservice code to OAuth2/OIDC, making multi-principal subjects difficult to implement in practice, and entirely exclude multi-protocol scenarios.

Authentication, Identity Propagation, and Authorization Patterns in Practice

Building on the story of Alice and the blog platform and the example in Authorization Patterns Recommendations, this section illustrates how the recommended patterns can be implemented in practice.

Extended Access Requirements

• Listing articles: Every user may view a list of articles, including the title, publication date, author, and a short excerpt.
• Reading articles: Access to the full content depends on the user’s subscription tier and the number of full articles already read that day. If the quota is exceeded or the user is anonymous, only an excerpt is shown. An exception applies for authors: an authenticated user may always read articles they wrote. Existing tiers are:
  • Free tier: up to 2 articles per day
  • Basic tier: up to 20 articles per day
  • Professional tier: unlimited
• Writing articles: Only professional-tier users may write. Before publication, an article must pass a harassment-content analysis. If rejected, the user is notified and warned. Warnings appear in the user’s private profile.

Resulting Services

To support these requirements, the following services may be implemented:

• Articles service – manages article storage and retrieval, as well as the number of the read articles, with latter being cleared each night.
• Subscription service – tracks user subscription tiers.
• Analysis service – performs harassment analysis and stores warnings
• Identity Provider (IdP) – handles registration, login, password reset, etc.
• Payment provider – processes subscription fees.
• Wiring application – assembles the UI and orchestrates calls to the other services, using appropriate UI integration patterns.

Mapping Requirements to Patterns

• Listing articles → Decentralized Service-Level Authorization
• Reading a full article → Modern Edge-Level Authorization to create the «authorization contract», enforced within the article service using Decentralized Service-Level Authorization
• Writing an article → secure identity propagation from the edge through the article service to the analysis service via Protocol-Agnostic Identity Propagation + Centralized Service-Level Authorization
• Reading warnings → Decentralized Service-Level Authorization
• Performing harassment analysis → same pattern as above
• Wiring application UI → checks only whether the user is authenticated; Decentralized Service-Level Authorization suffices
• In all cases → Modern Edge-Level Authorization protects endpoints so they cannot accidentally become public.
• To secure service-to-service traffic (article ↔ analysis, article ↔ PDP, etc.) Kernel-Level Authentication is used to ensure workload identity.

Possible OSS Stack

Implementing Kernel-Level Authentication typically requires Kubernetes. Projects such as Cilium, Istio (ambient mode), Linkerd, or other service-mesh implementations provide strong workload identity and mutual authentication for inter-service traffic.

For the IdP, social login via Google or Apple can cover registration and sign-in flows. To completely stay with the OSS stack, projects like Keycloak, Zitadel, Ory Kratos, or further can be used.

Modern Edge-Level Authorization and Protocol-Agnostic Identity Propagation can be implemented with the help of open-source projects such as Heimdall, Oathkeeper, Pomerium, or similar. In the walkthrough below I’ll use heimdall simply because I maintain it, and it’s the easiest way for me to illustrate the patterns. If Istio serves as the service mesh, Istio Gateway can act as the ingress, with heimdall integrated via Istio’s DestinationRule.

Because social login with Google requires an OIDC client functionality and heimdall (like many similar projects) does not implement it, an additional component is needed. oauth2-proxy is a well-known option for that purpose.

As the PDP, OPA, with OPAL acting as the control-plane component to distribute policies and data to OPA instances, could be used. However, any other PDP and matching control-plane solution could be used in the same way.

To ensure that authorization decisions always reflect the most recent state, an event bus is required. Services publish relevant events, which are then consumed by OPAL and distributed to the PDP instances.

In this example:

• The articles service emits an event each time a user reads an article. The event contains the heimdall-issued JWT together with the user’s updated “read articles” counter.
• The subscription service emits an event whenever a user changes their subscription tier.

This event-driven approach lets OPA react almost instantly to changes when evaluating policies. For reliable delivery, the event bus could be implemented with Apache Kafka, or lighter alternatives such as NATS, RabbitMQ, or similar.

Establishing a Canonical Subject and Enforcing a Deny-by-Default Posture

To establish a canonical subject and enforce a deny-by-default posture with heimdall one would define a so-called default rule:

default_rule:
  execute:
    # requires all requests "being authenticated"
    # via google
    - authenticator: google

    # denies all requests
    - authorizer: deny_all_requests

    # creates the canonical representation of the
    # external subject
    - finalizer: jwt

  on_error:
    # triggers authentication flow if the above
    # google authenticator fails and the request
    # was sent by a browser
    - error_handler: authenticate_with_google
      if: type(Error) == authentication_error && Request.Header("Accept").contains("text/html")

Each step in the two pipelines above (execute and on_error) references mechanisms from a predefined catalogue. This catalogue is part of heimdall’s configuration and can be tailored to the needs of a particular system. If required, a step can also customize the behavior of the chosen mechanism, as shown in the next section. Other projects similar to heimdall, may require full configuration for every step, or may implement a similar catalogue-based approach.

Service-Specific Rules and «Authorization Contracts»

Each service can now define deviations as needed. E.g. the wiring service would define a rule to expose public endpoints serving html and related content and another one to allow authenticated and anonymous requests to yet an additional endpoint:

apiVersion: heimdall.dadrus.github.com/v1alpha4
kind: RuleSet
metadata:
  name: "wiring app rules"
spec:
  rules:
    # allow authenticated or anonymous requests to 
    # the / route for GET requests
    - id: wiring-app:main-page
      match:
        routes:
          - path: /
        methods: [ GET ]
      execute:
        - authenticator: google
        - authenticator: anonymous
        - authorizer: allow_all_requests
        # jwt finalizer which creates the canonical 
        # representation of the external subject and the
        # error handler are reused from the default rule

    # allow all GET requests to any css, js, or ico
    # resources under / route
    - id: wiring-app:public-resources
      match:
        routes:
          - path: /:resources
            path_params:
              - name: resources
                type: glob
                value: "{*.css,*.js,*.ico}"
        methods: [ GET ]
      execute:
        - authenticator: anonymous
        - authorizer: allow_all_requests
        # jwt finalizer which creates the canonical 
        # representation of the external subject and the
        # error handler are reused from the default rule

The code used to render the html page behind the / route can use any standard JOSE library and the public key from heimdall’s .well-known/jwks endpoint to validate the issued JWT. This is a very simple application of the Decentralized Service-Level Authorization pattern. All services using Protocol-Agnostic Identity Propagation will see the same JWT structure and perform identical verification. And in case of the implementation to write articles, the articles service can simply pass the received JWT downstream to the analysis service along with the article to be verified.

Reading articles makes use of a wider range of Modern Edge-Level Authorization capabilities and establishes an own «Authorization Contract» by extending the JWT created by heimdall with some custom claims:

apiVersion: heimdall.dadrus.github.com/v1alpha4
kind: RuleSet
metadata:
  name: "articles service rules"
spec:
  rules:
    - id: articles-service:read-article
      match:
        routes:
          - path: /articles/:article_id
        methods: [ GET ]
      execute:
        - authenticator: google
        - authenticator: anonymous
        - authorizer: allow_all_requests
        # since the actual enforcement is done in
        # the implementation of the articles service
        # a contextualizer is used here instead of
        # an authorizer
        - contextualizer: opa
          config:
            values:
              policy: articles/allow
              action: read
              # the Subject object is created by the executed
              # authenticator
              subject: "{{ .Subject.ID }}"
              # article_id captures the value from the request
              # path defined in the match expression above
              object: "{{ .Request.URL.Captures.article_id }}"
        # extend the JWT configured in the default
        # rule with custom claims. A complete rewrite is
        # also possible instead.
        - finalizer: jwt
          config:
            values:
              requested_article: "{{ .Request.URL.Captures.article_id }}"
              allowed_representation: "{{ .Outputs.opa.result }}"

    # other rules, e.g. for requests to write an article

With that in place the implementation of the read article functionality can make use of these custom claims after verifying the JWT received along the request without the need to call OPA directly.

The article write functionality verifies the JWT issued by heimdall as already described for the other services in this example, calls OPA to understand whether writing of articles is allowed and enforces it. If allowed, the corresponding UI representation is rendered to the user. When ready, the user submits the article, resulting in the same checks, followed by a call from the article service to the analysis service for the harassment analysis. Since that check can take a while, the user is redirected to some page explaining the progress. The corresponding rule for heimdall would look similar to the wiring-app:main-page shown at the beginning of this section, but without a fallback to the anonymous authenticator.

Some Final Words

This concludes the series, but the work of applying these patterns and principles is just the beginning. You now have a framework for making informed decisions about authorization, identity propagation, and authentication — a practical toolkit for real-world microservice systems.

Remember: there’s no one-size-fits-all solution. Every system comes with unique requirements, constraints, and trade-offs. The patterns and recommendations shared here are meant to guide you, not dictate exact implementations. Treat them as a foundation on which to experiment, adapt, and refine your own approaches.

I hope this series inspires you to think critically about security architecture and empowers you to design systems that are not just functional, but secure, scalable, and maintainable. Your feedback, insights, and experiences are always welcome, so we can continue to learn from one another.