GH-1292: Support for bearer auth

[afs]

This resolves GH-1292.

The PR covers mainly client-side with a thin interface for responding to bearer auth 401 challenges. The application must a function to provide the token. There is little a standard library can do. The server side has some preparation work but again there has to be custom code somewhere to validate tokens in the deployment environment. This is probaly better done with a Fuseki module - cusomt code for Fuseki main as released.

[rvesse]

This PR is definitely a good first step and should get merged ASAP

The server side has some preparation work but again there has to be custom code somewhere to validate tokens in the deployment environment. This is probably better done with a Fuseki module - custom code for Fuseki main as released.

I would somewhat disagree with this. Certainly in the general case we probably can't support verifying every possible JWT that users might want to use (algorithms, key sources etc).

But for most everyday cases I think we could support a default verifier based on the following parameters that would be compatible with most OAuth2/OpenID Connect authentication providers:

• A JWKS file/URL, where JWKS is a JSON Web Key Set per RFC 7517 Section 5, from which the public keys for verifying a token can be obtained
• Optionally the claim to obtain the username from. This would default to sub but from practical experience the value of the sub field is often an internal system identifier rather than an actual username which is carried in a different claim.

This can be provided in a separate PR (and one which I'm happy to author myself)

[afs]

Environments where we might provide a solution are the major cloud providers.

The code can be delivered via a module that configures a servlet filter.