Original discussion: https://groups.google.com/g/irod-chat/c/rbvr47baFRc/m/oBiahnJtBQAJ
Currently, the introspection endpoint only uses the introspection response to map users:
|
// Use introspection endpoint if it exists |
|
static const auto introspection_endpoint_exists{ |
|
irods::http::globals::oidc_endpoint_configuration().contains("introspection_endpoint")}; |
|
if (introspection_endpoint_exists && validation_method == "introspection") { |
|
auto possible_json_res{openid::validate_using_introspection_endpoint(bearer_token)}; |
|
if (possible_json_res) { |
|
json_res = *possible_json_res; |
|
} |
|
} |
While some implementations provided additional information in the response, the only required response is whether the token is active, shown by the active member: https://www.rfc-editor.org/info/rfc7662/#section-2.2
We should look into providing the access token claims and the introspection response together if possible.
Some ideas:
- Provide the claims within the access token by default and fall back to the introspection response if the access token is not a JWT.
- Provide both the claims within the access token and the introspection response in a combined JSON.
- May require updating the user mapper to use JSON pointers.
Original discussion: https://groups.google.com/g/irod-chat/c/rbvr47baFRc/m/oBiahnJtBQAJ
Currently, the introspection endpoint only uses the introspection response to map users:
irods_client_http_api/core/src/common.cpp
Lines 374 to 382 in 25f1edc
While some implementations provided additional information in the response, the only required response is whether the token is active, shown by the
activemember: https://www.rfc-editor.org/info/rfc7662/#section-2.2We should look into providing the access token claims and the introspection response together if possible.
Some ideas: