-
Notifications
You must be signed in to change notification settings - Fork 30
Description
Problem
Currently, the TES API specification does not mandate implementers to require any authentication scheme. The specification merely mentions the following relevant paragraphs in its service description:
Is is envisaged that most TES API instances will require users to authenticate to use the endpoints.
However, the decision if authentication is required should be taken by TES API implementers.If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate.
Arguably, any public API must be protected from abuse by authentication (and authorization) policies, especially when offering access to compute resources, so mandating an authentication policy is prudent.
Moreover, enforcing at least one common, widely used authentication policy required to be supported by all implementations makes it considerably easier to design systems/environments in which multiple TES implementations are used concurrently, e.g., in federated TES networks.
Overview
OpenAPI currently (version 3.x) supports the following authentication (or authorization) schemes:
- Basic
- Bearer
- Other HTTP schemes as defined by RFC 7235 and HTTP Authentication Scheme Registry
- API keys in headers, query string or cookies
- OAuth 2
- OpenID Connect Discovery
Other GA4GH OpenAPI specifications define the following securitySchemes
:
Specification | SecuritySchemes | Applied |
---|---|---|
Data Connect | bearerAuth: type: http scheme: bearer |
Globally |
Data Repository Service (DRS) | BasicAuth: type: http scheme: basic description: | A valid authorization token must be passed in the 'Authorization' header, e.g. "Basic ${token_string}" BearerAuth: type: http scheme: bearer description: A valid authorization token must be passed in the 'Authorization' header, e.g. "Bearer ${token_string}" PassportAuth: type: http scheme: bearer x-in: body bearerFormat: JWT description: A valid GA4GH Passport must be passed in the body of an HTTP POST request as a tokens[] array. |
Globally |
Service Info | bearerAuth: type: http scheme: bearer bearerFormat: JWT |
Globally |
Service Registry | bearerAuth: type: http scheme: bearer bearerFormat: JWT |
Globally |
Tool Registry Service (TRS) | BEARER: type: apiKey name: Authorization in: header |
Individually for all endpoints |
Workflow Execution Service (WES) | N/A"Users must supply credentials that establish their identity and authorization in order to use a WES endpoint. We recommend that WES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. WES callers can use the |
N/A |
Beacon was omitted due to its complex structure of several OpenAPI specificatoin files, but does not appear to prescribe any authentication method
Bearer token authentication seems to be the consensus for those API specifcations that do prescribe authentication schemes, with the following exceptions:
- Next to bearer token authentication, DRS requires compliant implementations to also support basic and GA4GH Passport-based authentication schemes
- While the TRS
securityScheme
is calledBEARER
, it actually mandatesapiKey
-based authentication; assuming that its name expresses its intention to be used equivalently to bearer token authentication, this is presumably a remnant from migrating the specification over from Swagger/OpenAPI 2.x, where bearer authentication was not explicitly supported with its own scheme
Proposed solution
Mandate implementers to support JWT OAuth2 bearer tokens for authentication and apply it globally to all endpoints.
Alternative solutions
- Mandate basic authentication (as currently implemented in Funnel and TES-on-Azure)
- Mandate GA4GH Passport-based authentication (a more specific/constrained variant of the proposed solution)