That’s fair, yet more reasons why shared secrets should never have made a comeback.

Included the pretty-printing of the following token payloads on TRACE for the following appenders:

PROTOCOL_MESSAGE.OAUTH2:

• request objects - both direct (request=...) and via reference (request_uri=...)

• JWT access tokens

• JWT refresh tokens

PROTOCOL_MESSAGE.OIDC:

• ID tokens

• Back-channel logout tokens

Similarly to pretty-printing the JSON request/response messages, by default, the shibboleth.oidc.JSONObjectMapper bean is exploited, but a custom ObjectMapper bean may be wired via idp.oidc.logging.objectMapper -property.

I would probably suiggest using DEBUG and not TRACE, I think that’s what we do with the SAML protocol loggers. We just use the category to limit when they show up.

During the previous work on protocol message logging, I believe the main reason for leaving these raw OAuth2-protocol messages on TRACE was that in many cases they contain the raw client secrets. On DEBUG the protocol messages contain the authentication method (e.g. ...clientAuthentication=ClientAuthentication{clientId=test_rp_saml, method=client_secret_basic}..., as TRACE reveals the all the raw headers including Authorization:[Basic dGV... in that case.

I would probably suiggest using DEBUG and not TRACE, I think that’s what we do with the SAML protocol loggers. We just use the category to limit when they show up.

My personal preference would be to log anything relevant to the protocol in the PROTOCOL_MESSAGE.OAUTH2 category (I guess we could also do OIDC there as a suffix for things specific to it, most people will be logging all or nothing anyway).

But honestly as long as it’s clear how to do it, that’s all that matters. The formatting there is a vast improvement, thank you.

After just committed change, an example of the token response protocol message on TRACE is as follows:

(Previously the JSON was on single line.)

Secondly, it would be really nice to see traces of all the JWTs issued in JSON form and not strictly as encoded JOSE objects since those aren’t readable.

@Scott Cantor Should the contents of tokens (especially id_token in the example above) be human-readable in the protocol message trace, or is it satisfactory to have them human-readable via some other logger? Most probably from the logger of the SWF action that’s constructing the token?