search

inveniosoftware / invenio-oauthclient

Invenio module that provides OAuth web authorization support.
https://invenio-oauthclient.readthedocs.io
MIT License
6 stars 75 forks source link

contrib: migrate openaire sandbox to keycloak #297

Closed ppanero closed 1 year ago

ppanero commented 1 year ago
ppanero commented 1 year ago

blocked by https://zenodo-sentry.web.cern.ch/sentry/zenodo-rdm/issues/19978243/?query=is%3Aunresolved needs debugging

ppanero commented 1 year ago

tests are failing on flask babelex, guessing it requires https://github.com/inveniosoftware/invenio-oauthclient/pull/294

ppanero commented 1 year ago

@ntarocco it makes sense (If I understood correctly). Just to clarify, you are suggesting to have no alternative and always make the request? Something like:

def get_user_info(remote, resp_token):
    config_prefix = _generate_config_prefix(remote)
    return _get_user_info_from_endpoint(remote, config_prefix)

@max-moser was mentioning that in some cases using the token is preferred to save in number of requests. Another thing we were discussing with @slint was to request OpenAIRE to add the claims to the token, in which case we would not need to make the user info request. IIRC I understood (from Zach) that this is what we do with CERN. However, I'm not sure is the way to go since with that logic, what's the value of the user info endpoint?

max-moser commented 1 year ago

It's been quite a while since I first wrote the Keycloak integration, and it was my first real contribution to InvenioRDM... So I can't really tell with certainty anymore what the precise thoughts were behind it all :sweat_smile:

But IIRC, I just tried to save a few unnecessary network requests and reduce the attack surface. The user info endpoint probably was just added as a kind of "might as well just try that" in case something goes wrong with the initially passed token (e.g. if the encryption was invalid, ...).

shouldvedocumented