Faa Authentication

generated: '2026-07-28'
method: searched
source: >-
  openapi/*.yml in this repo, plus the FAA Gravitee developer-portal REST API
  (https://apim-api.apic4e.faa.gov/portal/environments/DEFAULT/configuration and
  /apis/{id}/plans), https://www.faa.gov/data, https://nms.aim.faa.gov/ and
  https://www.faa.gov/air_traffic/technology/swim/products/get_connected — all
  fetched 2026-07-28
docs: https://www.faa.gov/data
upgrades: >-
  Upgrades the 2026-07-28 derived pass, which saw only the two apiKey schemes in the
  SAS spec. The FAA's real credential model is wider than its securitySchemes: two
  APIs need no credential at all, one declares its credential as ordinary header
  PARAMETERS rather than a scheme, and the gateway itself has a key header that
  appears in no spec.
summary:
  types: [none, apiKey]
  api_key_in: [header]
  oauth2_flows: []
  oauth2: false
  oidc: false
  mtls: false
  key_issuance: self-serve account and application creation, then MANUAL approval per API
  headline: >-
    No OAuth 2.0 and no OpenID Connect anywhere in the FAA public API estate. Every
    credentialed FAA API is a static shared secret carried in a request header, with
    no token exchange, no expiry, no rotation policy and no scopes. Two APIs — the
    two most useful ones — need no credential at all.
schemes:
- name: none
  type: none
  applies_to:
  - FAA Airport Status Web Service (ASWS)
  - FAA Aeronautic Product Release API (APRA)
  - FAA NAS Status airport status information feed
  - FAA Temporary Flight Restriction (TFR) list API
  - FAA NMS North Atlantic Track NOTAM feed
  - FAA NMS system metrics feed
  - FAA Data Catalog (CKAN)
  - FAA AIS and UDDS ArcGIS Open Data hubs
  - Releasable aircraft registry bulk ZIP
  evidence: >-
    Neither the ASWS nor the APRA OpenAPI declares components.securitySchemes, both
    declare a Creative Commons Zero (CC0) licence, and the FAA's own Gravitee plan
    for each is KEY_LESS. Unauthenticated HTTP 200 verified on both, and on the TFR,
    NAS status and NMS feeds, on 2026-07-28.
- name: apiKey
  type: apiKey
  in: header
  parameter: X-API-KEY
  sources: [openapi/faa-safety-assurance-system-api-openapi.yml]
  applies_to: [FAA Safety Assurance System (SAS) API]
  applied: false
  applied_note: >-
    DEFINED in components.securitySchemes but never APPLIED — the SAS spec declares no
    root-level and no operation-level `security`, so tooling reads the operation as
    unauthenticated. Flagged in overlays/faa-safety-assurance-system-api-overlay.yaml.
- name: appId
  type: apiKey
  in: header
  parameter: X-APP-ID
  sources: [openapi/faa-safety-assurance-system-api-openapi.yml]
  applies_to: [FAA Safety Assurance System (SAS) API]
  applied: false
  note: Paired with X-API-KEY. Same never-applied problem.
- name: client_id + client_secret
  type: apiKey
  in: header
  parameter: client_id, client_secret
  declared_as: required header parameters on every operation, NOT a securityScheme
  sources: [openapi/faa-air-carrier-prd-api-openapi.yml]
  applies_to:
  - FAA Air Carrier PRD API
  - FAA NOTAM API
  evidence: >-
    All eight PRD operations declare both as `required: true` header parameters. An
    unauthenticated GET to https://external-api.faa.gov/notamapi/v1/notams returned
    HTTP 401 {"message":"Unauthorized","http_status_code":401} on 2026-07-28.
  weakness: >-
    A client SECRET carried as a plain request header with no token exchange, no
    expiry and no rotation policy — and modelled as a parameter, so generated clients
    and API tooling do not recognise the API as authenticated at all. This guards the
    most sensitive data in the FAA estate (pilot employment, training, drug/alcohol
    and disciplinary records).
- name: X-Gravitee-Api-Key
  type: apiKey
  in: header
  parameter: X-Gravitee-Api-Key
  sources: [portal configuration endpoint]
  evidence: >-
    https://apim-api.apic4e.faa.gov/portal/environments/DEFAULT/configuration reports
    the gateway apikeyHeader as X-Gravitee-Api-Key.
  note: >-
    The API-management gateway's own key header. Appears in no FAA OpenAPI, so a
    developer working from the specs alone would not know it exists.
onboarding:
  portal: https://api.faa.gov/
  portal_actual: https://portal.apic4e.faa.gov/ (301 from api.faa.gov)
  software: Gravitee.io APIM Developer Portal
  self_serve: true
  evidence: >-
    Portal configuration reports userCreation.enabled=true and
    applicationCreation.enabled=true. The FAA Data Portal says verbatim: "Developers
    can easily integrate FAA dataset into software applications thanks to the FAA's
    Application Programming Interfaces (APIs). Get started by creating an API key".
  approval: >-
    Every API_KEY plan in the portal is validation MANUAL — an account is self-serve
    but a subscription is approved by the FAA API owner. The Air Carrier PRD plan
    additionally sets comment_required, so a justification must be supplied.
  out_of_band:
  - api: FAA NOTAM Management Service (NMS)
    method: email request to notams@faa.gov
    source: https://nms.aim.faa.gov/
    verbatim: 'Please contact us at notams@faa.gov to request access to the new NMS-API.'
  - api: SWIM / SWIM Cloud Distribution Service
    method: executed FAA SWIM agreement via the SWIFT Portal
    source: https://portal.swim.faa.gov/
  - api: SWIM CDM, TFMS Request/Reply, TFMS International Data Provider
    method: email request to Data-To-Industry@faa.gov, reviewed in accordance with FAA policy
  - api: LAANC
    method: only through an FAA-Approved UAS Service Supplier, never directly
eligibility_gates:
- api: FAA Air Carrier PRD API
  gate: regulatory
  verbatim: >-
    "Access is restricted to operators under Part 121, 135, 125, 91K, Air Tour, Public
    Aircraft, or 91 Corporate. Requests for access from any other public or private
    entities will not be authorized."
  source: FAA Gravitee portal catalog record
scopes:
  present: false
  note: >-
    No OAuth means no scope surface. This repo deliberately carries no scopes/
    artifact — see conventions/faa-conventions.yml.
discovery:
  oauth_authorization_server: 404 on every FAA host probed
  openid_configuration: 404 on every FAA host probed
  source: well-known/faa-well-known.yml
gaps:
- No OAuth 2.0 / OIDC anywhere, so no delegated access and no consent model.
- No scopes, so no least-privilege credential for any FAA API.
- No documented key rotation, expiry or revocation policy.
- The PRD credential is modelled as a parameter, not a security scheme.
- The SAS security schemes are defined but never applied.
- The gateway key header appears in no published spec.