Support OIDC tokens as a method of authenticating with the Galaxy API

[nuwang]

tl;dr;

This proposal describes modifications to Galaxy that will allow Galaxy to authenticate and authorize requests containing OIDC bearer tokens, as an alternative to, and and an eventual replacement for, API tokens.

Background

While Galaxy supports OIDC based login, it does not currently support OIDC for API authentication. Instead, it accepts an API token for authenticating the user. This API token is included in the request header with each API call. Once an API token is accepted, the user is authorized to carry out any action that the user is capable of performing.

The OIDC standard in contrast, supports scoped bearer tokens. Bearer tokens are JWT tokens that are included as part of the HTTP request header (Authorization: Bearer tokendata), and can be considered analogous to an API key. However, bearer tokens also allow specific scopes (permissions) to be granted to that token, further limiting the power it wields, in contrast to an API key.

Additionally, OIDC bearer tokens can enable single-sign on between backend services, allowing seamless access to Galaxy from other services.

Related issues

Scoped tokens have been proposed previously (#1524) and (#13737), and serve the same aim of providing restricted API access. This proposal breaks things down further into a series of incremental changes that can be implemented over time to achieve the same aim.

Proposal

This proposal suggests that initially, OIDC tokens from remote sources are accepted as a substitute for an API key. This would provide the immediate benefit of enabling external services to have single-sign-on access to the Galaxy API.

A second stage enhancement would be to respect any scopes specified in the token, limiting API access only to the surface defined by those scopes.

As a potential late stage enhancement, @uwwint has suggested replacing existing API tokens with scoped oauth tokens, with Galaxy becoming an OIDC token issuer of its own. From a usage point of view, the API key would instead become a lengthier JWT token, but otherwise still be an opaque token, meaning that bioblend and other remote services would not require any changes, apart from having to accomodate a longer key length.

Implementation details

When an OIDC token is presented as part of a request, Galaxy will attempt to decode the token and identify the issuer of the token. If the issuer is a known issuer from the currently registered list of issuers in the OIDC config file, the token will be verified against that issuer. If the token is valid, and the subject (user id) is already registered with the system, the token will be accepted as an API token for that user.

Funding

This would be funded by the Australian BioCommons as part of its efforts to integrate the BPA Data Portal with Galaxy Australia, enabling seamless access between the two systems.

Any comments would be welcome.

[SergeyYakubov]

Sounds great!

It should be relatively easy to implement for Galaxy Web interface (and probably make it update tokens, not Galaxy server like now), but there might be an issue with non-web clients like bioblend and other services due to token expiration. One would need to provide a fresh token to those services somehow. Maybe still keep API tokens for now, or have an option to generate a JWT token with scope, but without expiration in Web interface.

[nuwang]

Closed by: #16977