I am wondering if it is desirable to add extended checks on a response obtained as a result of a token introspection request. The code below seems to grant access to protected resources as long as a bearer token is still active and its associated user exists in iRODS:
What happens if a valid and active bearer token meant for another app/client, but for a valid iRODS user, is presented to the API server? Would this be let in? Could the token validation be performed also on the response client_id and aud? For instance, I could imagine an extra configuration parameter called audience to add an extra level of security
std::string aud = irods::http::globals::oidc_configuration().at("audience").get_ref<const std::string&>();
if (json_res.at("aud").get<string>() != aud) {
logging::warn("{}: Access token is not meant for me.", __func__);
return {.response = fail(status_type::unauthorized)};
}
ll4strw
commented
7 months ago
I am wondering if it is desirable to add extended checks on a response obtained as a result of a token introspection request. The code below seems to grant access to protected resources as long as a bearer token is still active and its associated user exists in iRODS:
https://github.com/irods/irods_client_http_api/blob/48b63758b056e11008a6b1e876f0ed427a3f39c2/core/src/common.cpp#L402-L429
What happens if a valid and active bearer token meant for another app/client, but for a valid iRODS user, is presented to the API server? Would this be let in? Could the token validation be performed also on the response
client_idandaud? For instance, I could imagine an extra configuration parameter calledaudienceto add an extra level of securityThanks in advance, L.