Will authentication be implemented? How?

[stuartpullinger]

Will the Search API only expose open data or will some data require authentication? How will this be implemented? Will there be a token carried in the HTTP Headers?

(I suppose I have not understood what are Work Package 4's requirements for this API).

(Including @louise-davies and @agbeltran in the discussion)

[garethcmurphy]

Open data will be shared over harvest-api. Search-api will include open data and also embargoed data, so will require login via umbrellaid/orcid which is from WP6.

The WP6 slides are below https://indico.esrf.fr/indico/event/36/session/36/contribution/21

[RKrahl]

This does not answer the question how this is going to be implemented. I assume that the Umbrella AAI is able to generate some sort of a token suitable to identify a user, although I don't know enough details to understand the mechanism. But then, there are still at least two possible options:

1. send that token with each request that requires authentication.
2. use that token in some kind of a login call that returns a session id and then send the session id with each request.

I assume that the second option would be more efficient, because verifying an authentication token is likely more costly then checking a session id from a simple db look up. I guess we would need some input from WP6 people here.

[zjttoefs]

Authentication will not be required. An authenticated session will have access to the embargoed data the user has access to. For the "How" part, we're still in discussions with WP6. So for the moment, we're focussing on open data.

[jamhall]

@RKrahl WP6 will provide us with a couple of protocols, primarily OpenIdConnect and SAML. I would imagine that, for ease of use and to reduce the complexity we will likely use the OpenIDConnect protocol.

For the WP3 API - I would stipulate that an Authorization header will be sent for endpoints that require authorisation.

Authorization: Bearer <token>

This JWT token will contain the relevant scopes (user attributes). The API will validate this token against the authentication endpoint (the cost factor is negligible).

For obtaining said token, the Data Analysis portal will provide the login endpoint using OpenId Connect and implicit flow (used for SPAs).

[RKrahl]

The API will validate this token against the authentication endpoint (the cost factor is negligible).

If the API endpoint needs to do this for each request, I guess the costs will not be negligible. But ok, the solution might be to cache the validation result. Then it's an implementation detail in the API endpoint at the local metadata catalogue, so it doesn't need to be solved in the API itself.

[jamhall]

We can't cache the validation results. JWT tokens are issued with a short expiration time so that the application is forced to continually refresh them. Normally tokens are only valid for 5 minutes (keycloak default for example). JWTs are signed using a secret (with the HMAC algorithm). When a token is validated, there is no database lookup. The signature is verified against an issuer and checks the token has not expired. Required user information is stored in the payload (scopes). This information can be used to do further checks for authorisation (at the API level)

EDIT: To clarify. authorisation requests could be cached but authentication requests cannot be.

EDIT2: If we would like to have clients to use the API that are not going through a web interface i.e. like facebook when you want to create an app then we could consider using Oauth2, but that seems to be outside of the scope of the API for the moment.

None of this has been confirmed for the moment. Just my two cents :)