APM OIDC debug logging is somehow verbose but not where it should - RFE

Forums Technical Forums
1

While I was configuring and testing an APM Access policy for an OIDC integration with Entra ID, I was seeing some backchannel errors logged (debug level) some HTTP error 400.
The whole logging is quite verbose, but here, not very useful:

<br>[...]<br>OAuth Client: failed for server '/Common/entraid_test' using 'authorization_code' grant type (client_id=xxxxxxxxxxxxxx), error: HTTP error 400,<br><br>Session variable 'session.oauth.client./Common/entra_front_act_oauth_client_ag.errMsg' set to 'HTTP error 400, '<br><br>Session variable 'session.oauth.client./Common/entraid_test.errMsg' set to 'HTTP error 400, '<br><br>Session variable 'session.oauth.client.last.errMsg' set to 'HTTP error 400, '

So, tcpdump was required to see what exactly the error was in the returned JSON payload from Entra ID.

I’ve got a new RFE from F5 support =>
(Bug alias 2229965) [RFE] Add extra verbosity for the debug-level logging for OIDC backchannel connection

Don’t hesitate to open a support case to get it bound to that RFE, the more we are the higher priority will be assigned to implement it (hopefully). :grinning_face:

Alexandre

2

Hello @amolari

Could you paste here your configuration, oauth server, access policy, etc ?

3

Hello Kostas,

it’s not a recent case, I don’t have the config handy anymore. It was a complicated case with Entra ID, issues with the Tenant that was initially not working as expected (Microsoft support involved etc..)
In the 400 json payload some helpful information:
“error”: “invalid_request”
“error_description”: "AADSTS50146: This application is required to be configured with an application-specific signing key. It is either not configured with one, or the key has expired or is not yet valid. Trace ID: db2a04a0-7d54-4d37

No issue using tcpdump, but it takes longer time in some customer environments until one can display the capture in wireshark…

4

Ok I see