Migrate from openEO-specific tokens to JWT #558

[m-mohr]

Closes #558 and #338

Should be fully backward compatible as specified.

[soxofaan]

One conflict that I'm still pondering on:

The basic auth option does not play nicely with JWT I think. The point of basic auth is to have a very simple, low overhead auth mechanism (a single /credentials/basic endpoint to produce tokens and the generic Authorization header for consumption). This is ideal for sandboxed testing/benchmark use cases, where one doesn't want to spend too much effort on a full auth stack.

To support JWT and the related mechanisms however you need to do quite a bit more: you have to set up an internal issuer service, possibly manage secrets (for signing), support multiple extra endpoints (.well-known/openid-configuration, /token, /userinfo, ...)

I'm not sure we should aim for removal of the openEO token format, as it will make basic auth practically unusable.

I would aim for something like:

• OIDC:
  • recommend standard JWT
  • deprecate openEO token format, possibly removing support in later openEO API version
• basic auth:
  • keep openEO token format
  • allow JWT usage, but nobody is probably going to do that

[m-mohr]

Is that really the case? Can't you just create a JWT using one of the JWT libraries? JWT is completely independant of OIDC, you certainly don't need the extra endpoints. https://jwt.io

[soxofaan]

some additional suggestions to further clarify the subtle differences between access and bearer tokens

[soxofaan]

Is that really the case? Can't you just create a JWT using one of the JWT libraries? JWT is completely independant of OIDC, you certainly don't need the extra endpoints.

Creating JWT tokens is indeed not a problem. The problem is that the backend must decode and verify that the tokens effectively come from the trusted OIDC issuer. So as far as I currently understand, you need one of:

• get some public pub key of the OIDC issuer (a .well-known mechanism) to use in signature verification
• send the token to the /userinfo endpoint of the issuer (which also involves discovery from .well-known/...) to let the issuer do the verification

And I even think that the second option is necessary to obtain extra info that is not in the token itself (e.g. user roles or that virtual org membership stuff from EGI)

Using /userinfo to do the verification and enrichment is what we currently do in the VITO implementation FYI

[m-mohr]

Well, but if the backend detects that it's from basic (e.g. by including that into the JWT), it can just skip all OIDC stuff and just check whether that token is valid. Whatever that means for the Basic JWT tokens, is up to the provider to decide. I don't really see a big difference to before, except that it's now JWT encoded.

I'll go through the proposed textual changes after next week. :-)

[soxofaan]

did another quick review round

[m-mohr]

@soxofaan I think all comments have been resolved. Can you re-review, please?