OAuth2 Filter: Adding response_code_details for 401 cases

[denniskniep]

Description:
There are a lot scenarios where OAuth2 Filter returns 401 status code. But in AccessLog there is no further detail why it was a 401. That makes troubleshooting hard. You have to switch to debug logging if you want more insights.

Example:
"response_code":"401","response_flags":"-","response_code_details":""

We should enrich it with a short explainer:

envoy/source/extensions/filters/http/oauth2/filter.cc

Lines 859 to 863 in 2425431

	void OAuth2Filter::sendUnauthorizedResponse() {
	config_->stats().oauth_failure_.inc();
	decoder_callbacks_->sendLocalReply(Http::Code::Unauthorized, UnauthorizedBodyMessage, nullptr,
	absl::nullopt, EMPTY_STRING);

Like this:

envoy/source/extensions/filters/http/oauth2/filter.cc

Line 759 in 2425431

decoder_callbacks_->encodeHeaders(std::move(response_headers), true, REDIRECT_LOGGED_IN);

results in "response_code":"302","response_flags":"-","response_code_details":"oauth.logged_in"

cc: @zhaohuabing

[denniskniep]

Plz assign me on that issue

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[denniskniep]

Not stale

[solsson]

I interpret this issue as a proposal, and if I understand it correctly I'm definitely +1.

In production (with Keycloak as authorization_endpoint) we've always had a non-zero rate of envoy_http_oauth_failure, but after upgrading to Envoy 1.32 we had many users that reported seeing an OAuth flow failed error page. We guessed that it was #36871 and downgraded to 1.31 and the failure rate went back to normal.

The reason we guessed is that there is (in current main) six places that call sendUnauthorizedResponse. There's no error type passed with that call and thus oauth_failure_.inc() has no distinguishing label. ENVOY_LOG is done prior to some of the calls but not all, so counting log entries is also insufficient for classifying the errors.

My interpretation is that oauth_failure isn't necessarily an error condition. Both these additions would help maintenance a lot:

• Consistently logging the trigger for sendUnauthorizedResponse
• A metric label that gets a value that is unique for each call to sendUnauthorizedResponse

@denniskniep Does this relate to your idea for the issue?

[denniskniep]

@solsson yes, that is exactly what I had in mind.

Not sure when I have time to start working on it, but hopefully soon ;-)

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.