You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
"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 auth_instructions_url from the service-info endpoint to learn how to obtain and use a bearer token for a particular implementation."
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 TRSsecurityScheme is calledBEARER, it actually mandates apiKey-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 JWTOAuth2 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)
The text was updated successfully, but these errors were encountered:
While the TRSsecurityScheme is calledBEARER, it actually mandates apiKey-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
Very possible. The other part of the explanation is that the endpoints are default public.
i.e. If a workflow is public, you don't need auth, you only need auth if the workflow is not public yet
In other words, auth isn't heavily used yet AFAIK
We should probably fix the security scheme before it is
Good point @denis-yuen. Although it's probably still good practice to implement an authentication scheme in TRS implementations to better guard against, e.g., DDoS attacks. And as it is, as long as you define anysecurity Scheme in the specs and apply it, fully compliant implementations would have to support it. Which, for TES, is the main reason why we, or at least I, want to put it in. But your mileage may vary for TRS.
But if you wanna keep it in, I agree that it's probably a good idea to change it.
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:
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:
Other GA4GH OpenAPI specifications define the following
securitySchemes
:bearerAuth:
type: http
scheme: bearer
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.
bearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
bearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
BEARER:
type: apiKey
name: Authorization
in: header
Bearer token authentication seems to be the consensus for those API specifcations that do prescribe authentication schemes, with the following exceptions:
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 schemeProposed solution
Mandate implementers to support JWT OAuth2 bearer tokens for authentication and apply it globally to all endpoints.
Alternative solutions
The text was updated successfully, but these errors were encountered: