Never trust, always verify. Every request to AeroScope's aviation data API must present valid credentials scoped to exactly what it needs. No blanket access, no ambient authority, no exceptions.
The principle that killed perimeter security
Traditional API security draws a line around a network and assumes everything inside that perimeter is safe. Authenticate once, get a session cookie, and the server trusts every subsequent request without re-checking what you're actually allowed to do. That model collapses the moment a single token leaks or an insider goes rogue. One compromised credential and the attacker has the same blanket access the legitimate user had.
Zero-trust inverts that assumption entirely. No request is trusted by default, regardless of where it originates or what credentials accompanied previous requests. Every API call to AeroScope must present a valid JSON Web Token containing specific capability claims that describe exactly which endpoints and actions the caller is permitted to use. The server verifies the token's cryptographic signature, checks its expiry, and then inspects whether the encoded capabilities cover the specific resource and action being requested. A token that grants aircraft:read cannot write geofences. A token scoped to threats:read cannot export data. There is no escalation path within a single token.
This matters for aviation data. Flight positions, threat scores, military transponder classifications, and airspace intelligence carry operational sensitivity. A research integration that needs aircraft positions should not, even accidentally, gain access to threat assessment internals or administrative configuration endpoints. Zero-trust ensures that the blast radius of any compromised credential is limited to the exact capabilities that credential was issued.
The practical result: AeroScope treats every inbound request as potentially hostile. Identity is verified. Capabilities are checked against the requested action. Rate limits are enforced. The full request is logged for audit. Only then does data flow back to the caller.
Five steps from request to verified response
Step 3 is where zero-trust diverges from standard JWT authentication. A conventional system might issue a token that says "this user is authenticated" and leave authorization to middleware that checks a role database. AeroScope embeds the authorization directly in the token as a capabilities array. The token itself declares what the bearer can do, and the server enforces those declarations at every endpoint without a secondary lookup.
Authorization encoded in the credential itself
Each JWT issued by AeroScope contains a capabilities claim: an array of strings describing permitted actions at endpoint granularity. When a request hits the server, middleware decodes the token and checks whether the capabilities array includes the permission required for that specific route and HTTP method.
The sub field identifies the user. The capabilities array defines exactly what this token authorizes. An analyst might get read access to aircraft, threats, geofences, intel, and exports, plus write access to geofences so they can define monitoring boundaries. But they would not receive admin:write or admin:read, so any request to administrative endpoints returns a 403 regardless of the token's validity.
The server maintains a static mapping between roles and default capability sets. When a user authenticates, their role determines which capabilities are embedded in the issued token:
This is not a role-based access control (RBAC) system in the traditional sense. The role determines the initial capability set, but the enforcement happens on the capabilities themselves. The server never checks "is this user an analyst?" at the endpoint level. It checks "does this token contain geofence:write?" That distinction matters because it means capability sets can be customized per integration without changing role definitions.
Endpoint access by role
| ENDPOINT | PUBLIC | AUTHENTICATED | ANALYST | ADMIN |
|---|---|---|---|---|
| Aircraft Data/api/aircraft | ✓ | ✓ | ✓ | ✓ |
| Threat Scores/api/threats | ✗ | ✓ | ✓ | ✓ |
| Geofence ReadGET /api/geofence | ✗ | ✓ | ✓ | ✓ |
| Geofence WritePOST /api/geofence | ✗ | ✗ | ✓ | ✓ |
| Intelligence/api/intel | ✗ | ✗ | ✓ | ✓ |
| Data Export/api/export | ✗ | ✗ | ✓ | ✓ |
| Admin Config/api/admin/config | ✗ | ✗ | ✗ | ✓ |
| Admin Users/api/admin/users | ✗ | ✗ | ✗ | ✓ |
Each cell represents a capability check, not a role check. The green marks indicate the role's default token includes the required capability. Hover over any mark to see which specific capability string is being evaluated. This is the enforcement layer that runs on every single request.
Real-time request auditing and threat detection
| STATUS | METHOD | ENDPOINT | USER | LATENCY | RESULT |
|---|---|---|---|---|---|
| 200 | GET | /api/aircraft | user_456 | 12ms | OK |
| 200 | GET | /api/threats | user_789 | 8ms | OK |
| 200 | GET | /api/geofence | user_456 | 6ms | OK |
| 403 | POST | /api/admin/config | user_456 | 2ms | INSUFFICIENT_CAPABILITY |
| 200 | POST | /api/geofence | user_789 | 14ms | OK |
| 429 | GET | /api/aircraft | anon_012 | 1ms | RATE_LIMITED |
| 403 | GET | /api/intel | anon_034 | 1ms | INSUFFICIENT_CAPABILITY |
Every request is logged with its timestamp, source IP, authenticated user, requested endpoint, response status, and latency. The 403 entries in the log above show the system working as designed: user_456 has analyst-level capabilities and attempted to POST to an admin endpoint. The token was valid, the signature checked out, but the capabilities array did not include admin:write. Access denied in 2ms, logged, and the response tells the client exactly why.
Every request passes through six verification stages
Failure at any stage short-circuits the chain. If TLS negotiation fails, the connection never establishes. If the token is malformed or the signature doesn't match the server's HMAC-SHA256 secret, the request gets a 401 before capability checking even begins. If the token has expired, same result. Only requests that clear all six stages receive data. This layered approach means an attacker would need to simultaneously compromise the transport layer, forge a valid signature, and possess a non-expired token with the correct capabilities to access any protected resource.
Defense in depth across the full request lifecycle
All data in transit is encrypted with TLS. The server enforces a minimum of TLS 1.2 and prefers 1.3 cipher suites. Certificate pinning is available for high-security integrations. Cleartext HTTP requests are redirected to HTTPS with a 301.
Tokens are signed with HMAC-SHA256 using a server-side secret. Expiry is fixed at 24 hours from issuance. The server rejects tokens with clock skew beyond 30 seconds. No refresh tokens are issued; clients must re-authenticate after expiry to force credential re-validation.
Each endpoint declares its required capability. Middleware extracts the token's capabilities array and performs a set-membership check. This runs in O(1) against a pre-computed Set object. No database query, no role lookup, no external service call.
REST endpoints: 60 requests per minute per token. Export endpoints: 10 requests per minute. WebSocket connections: 5 concurrent per user. Limits are enforced via an in-memory sliding window counter keyed by token subject. Exceeding the limit returns 429 with a Retry-After header.
All query parameters and request bodies are validated against schema definitions before processing. Numeric ranges are enforced (latitude -90 to 90, longitude -180 to 180). String inputs are sanitized against XSS and SQL injection patterns. Malformed input returns 400 with specific field-level error descriptions.
Every request is logged with: ISO 8601 timestamp, source IP, authenticated user ID, HTTP method, endpoint path, response status code, response time in milliseconds, and capability match result. Logs are structured JSON written to rotating files with 30-day retention.
Request and response patterns
Notice that the 403 response explicitly states which capability was required and what the token actually contained. This is a deliberate design choice: in a zero-trust system, the client should understand exactly why access was denied so it can request appropriate credentials or adjust its behavior. Obscuring the reason would make debugging harder without meaningfully improving security, since the capability model is documented publicly.
Where zero-trust matters most
Organizations running AeroScope for multiple clients can issue separate tokens with distinct capability sets. One client sees aircraft data only; another gets full threat analysis access. Tenant isolation is enforced cryptographically in the token itself, not by application logic that could be bypassed.
Academic researchers working with flight pattern data need aircraft positions and historical tracks. They do not need threat scores, admin panels, or geofence controls. A research-scoped token grants exactly aircraft:read and export:read, limiting exposure of sensitive operational data.
External systems consuming AeroScope data via API can be issued narrowly scoped tokens that match their integration requirements. A flight display board needs aircraft:read. An alerting system needs geofence:read and threats:read. Neither gets more than it needs.
Defense and civil aviation authorities require auditable access controls with documented permission boundaries. The capability token model provides a self-describing audit trail: every token encodes its own permissions, and every request is logged against those permissions. Compliance auditors can verify exactly who accessed what and when.
Zero-trust means no request is inherently trusted. Every API call must present a valid JWT token containing specific capability claims. The server verifies both the token signature and whether the claimed capabilities cover the requested endpoint and action. This applies to every request, whether it comes from inside or outside the network.
Tokens expire after 24 hours from issuance. After expiry, clients must re-authenticate to obtain a fresh token. This limits the window of exposure if a token is compromised. There are no refresh tokens by design; re-authentication forces credential re-validation every 24 hours.
REST endpoints allow 60 requests per minute. Export endpoints allow 10 per minute. Exceeding these limits returns a 429 Too Many Requests response with a Retry-After header indicating when the next request will be accepted. Rate limits reset on a sliding window, not a fixed minute boundary.
Capabilities are assigned based on your authenticated role. Public users receive read-only access to aircraft data. Analysts gain threat and intel read access. Admins receive full read/write across all endpoints. Custom capability sets can be configured for API integrations by contacting the platform administrator.