Apollo SEC Frontend

Andi Lamprecht ·2026-05-11· 6 min read· Accepted

Security Perimeter - Apollo with Frontend

Security is understood here as a set cybersecurity strategies that prevents unauthorized access to organizational assets such as computers, networks, and data. It maintains the integrity and confidentiality of sensitive information, blocking the access of sophisticated hackers.

Apollo is a multi-tenant backend application running within a secure containment of a Kubernetes cluster. This means that no external traffic will appear within it unless admitted either by the:

• UAV’s Avatar.
• Kubernetes ingress controller and the API gateway in front of it (today this is Kong).

This ADR deals with the latter

Context

The API gateway is expected to bind and listen at one or many public IP addresses, terminate TLS and reverse proxy the incoming traffic towards the intra-cluster Apollo microservices. The API gateway and Kubernetes ingress controller are ideally one and the same reverse proxy, but they could be separate in some deployments without changing much about the security.

Intra-cluster encryption is not of interest to Apollo, but is assumed to be in place and of interest by the Platform Engineering team.

What is of Apollo interest is authenticating and authorizing calls incoming via the API gateway from Apollo’s clients (e.g.: browsers, HubOps). Apollo therefore expects Kong not to perform any form of authorization, though it does expect it to protect it from DoS (or similar) attacks.

OAuth 2.0

OAuth, which stands for “Open Authorization”, is a standard designed to allow a website or application to access resources hosted by other web apps on behalf of a user. By introducing an authorization layer and separating the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner. OAuth defines the following roles:

Resource Owner - An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.

Resource server - The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

Client
An application making protected resource requests on behalf of the
resource owner and with its authorization. The term “client” does
not imply any particular implementation characteristics (e.g.,
whether the application executes on a server, a desktop, or other
devices).

Authorization server
The server issuing access tokens to the client after successfully
authenticating the resource owner and obtaining authorization.

It would be then OAuth 2.0 that would allow an Apollo user (resource owner) authorize the Apollo frontend webapp (client) to access their resources hosted by the Apollo backend (resource servers). The authorization takes the form of an access token issued to the client by the authorization server as instructed by the resource owner with one of the OAuth-supported grants.

Even though authentication is implicit within the OAuth flows, OAuth is expressly an authorization framework, i.e.:

OAuth 2.0 does not provide a mechanism to say who a user is or how they authenticated, it just says that a user delegated an application to act on their behalf. The OAuth 2.0 framework provides this delegation in the form of an access token, which the application can use to act on behalf of the user.

Access tokens provide an abstraction layer, replacing different
authorization constructs (e.g., username and password) with a single
token understood by the resource server. This abstraction enables
issuing access tokens more restrictive than the authorization grant
used to obtain them, as well as removing the resource server’s need
to understand a wide range of authentication methods. Access tokens can have different formats, structures, and methods of
utilization (e.g., cryptographic properties) based on the resource
server security requirements. Access token attributes and the
methods used to access protected resources are beyond the scope of
this specification and are defined by companion specifications such
as [RFC6750].

This is to say that OAuth 2.0 doesn’t mandate the contents of the access token nor a manner of using this contents for granting access.

Identity Providers and OIDC

Identity Providers (IdP) are services that offer a method of authenticating Security Principals (e.g.: users). Some of these services, like Keycloak, Auth0, Onelogin and Okta, are also OAuth 2.0 authorization servers, i.e.: they compliment OAuth 2.0 with a method of authenticating and they typically adhere to the OIDC of doing so.

Decision

Apollo will use OAuth 2.0 for authorizing calls. More specifically:

• A security Principal, e.g.: a user, Operator or a machine/automaton.

• will authenticate with an Identity Provider that DroneUp chooses (e.g.: Auth0).

• and authorize the Apollo client either via the

  • Implicit Flow (for single page web applications, such us the Apollo Web Frontend, that can’t store a secret).
  • Client Credentials Flow (for machines) or
  • Authorization Code Flow (for native applications that can store a secret)

• thus exchanging the Principal’s credentials/secrets for a JWT access token.

• They will affix such access token as the Authorization Bearer header to every (now necessarily https) API call towards Apollo;

• Each Apollo service will authenticate the call by validating the authenticity of the JWT token and verifying the token’s signature against the Identity Provider’s public signing key (which may be rotated);

• Each Apollo service (acting as an OAuth 2.0 resource server) will authorize the call by checking the JWT’s contents for relevant claims. Notably; a caller may request a resource with a specific ID (e.g.: a mission with the id abc). The Mission service might grant the RO access to this mission in three circumstances:

  • if the mission is assigned to the user and user is an operator.

  • if the mission is to be flown at the Bentonville Hub and the user is a Bentonville safety_officer.

  • if the user is a DroneUp operational admin.

    The assignment of Operators to Missions and Missions to UAVs granted by the Apollo business logic will be visible to the Avatar by one of the following means:

    • Asking the Mission service or being told by the Mission service at the onset;
    • Asking an intermediary source of truth like a DB or Redis cache for this assignment.

    These circumstances make it difficult for an Apollo service to delegate authorization some place else (like Cerbos), because claims/roles alone aren’t sufficient to resolve access. It’s not sufficient to see if a user is an operator as the Mission Service must ask the Mission Database whether the mission is assigned to this operator.

    It is not in scope for this ADR to chose the authorization model (e.g.: RBAC, ABAC or ReBAC) and so neither it is in scope to state what the relevant claims are. Suffice to say that the claims will become a contract between the Apollo resource servers and the configuration of the Identity Provider and the identities it hosts. As such the claims need to be documented and discoverable.

Consequences

None standing out.

Alternatives Considered

Session based authentication has been briefly considered and discarded as it puts the burden of handling credentials onto the AirBoss servers and prevents federating authentication.

Cited by queries

• DroneUp roles and permissions: as-is across Uncrew, Hubops, UTM, Boundary Creator, Frontegg, Okta, and Lumos — 2026-05-01