You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Need logging or better response around auth rejection reason
#20221
It would be good to have more specific logging when an authentication or authorisation is rejected. This would help identify why a user is being rejected and help admins and devs more quickly resolve the issues leading to this.
Alternatively to provide a mode where the error responses provide a bit more of a clue as to the rejection reason.
I am curious to get other views on this or whether it is something that is considered worthwhile?
The background (partly to help others and to give a reasoning for others):
Yesterday we were running into an issue when trying to get the user profile of an authenticated user. This user was a service account of another service making an API call to our server. The rejection (403 status, access_denied) was coming when we using the bearer token of the connecting account to get user profile (/realms/*/protocol/openid-connect/userinfo) from Keycloak.
We did try enabling looking the events log and console logs, but the best we got was:
Switching logging level to debug resulted in an overload of database related logging, rather than anything that could be seen a clear reason (if it was there, then it was lost in the noise).
We did look at content of the jwt token, comparing it to one that worked, discounted what might have been the cause, only to circle back a couple of hours later to what we had rejected as a possible reason. We rejected the issue being on the connecting server, since this flow had worked a number of months prior and before we made the a recent Keycloak upgrade.
The reason ended up being that the connecting service wasn't requesting the 'openid' scope when it was doing the token exchange on its side. This was clear in any of the documentation we were looking at, so we tried it more from the angle of a hunch and taking a chance. With this change in place were able to get the user profile.
If the logging or the error response, for the 403, had indicated the missing scope was the reason for the rejection, then I believe we would have spent 10 minutes resolving this, as opposed to 2 hours. I appreciate a certain amount of obscurity is useful, but not when trying to resolve administration or development issues.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
It would be good to have more specific logging when an authentication or authorisation is rejected. This would help identify why a user is being rejected and help admins and devs more quickly resolve the issues leading to this.
Alternatively to provide a mode where the error responses provide a bit more of a clue as to the rejection reason.
I am curious to get other views on this or whether it is something that is considered worthwhile?
The background (partly to help others and to give a reasoning for others):
Yesterday we were running into an issue when trying to get the user profile of an authenticated user. This user was a service account of another service making an API call to our server. The rejection (403 status, access_denied) was coming when we using the bearer token of the connecting account to get user profile (
/realms/*/protocol/openid-connect/userinfo) from Keycloak.We did try enabling looking the events log and console logs, but the best we got was:
Switching logging level to
debugresulted in an overload of database related logging, rather than anything that could be seen a clear reason (if it was there, then it was lost in the noise).We did look at content of the jwt token, comparing it to one that worked, discounted what might have been the cause, only to circle back a couple of hours later to what we had rejected as a possible reason. We rejected the issue being on the connecting server, since this flow had worked a number of months prior and before we made the a recent Keycloak upgrade.
The reason ended up being that the connecting service wasn't requesting the 'openid' scope when it was doing the token exchange on its side. This was clear in any of the documentation we were looking at, so we tried it more from the angle of a hunch and taking a chance. With this change in place were able to get the user profile.
If the logging or the error response, for the 403, had indicated the missing
scopewas the reason for the rejection, then I believe we would have spent 10 minutes resolving this, as opposed to 2 hours. I appreciate a certain amount of obscurity is useful, but not when trying to resolve administration or development issues.All reactions