It should be easy to configure an audit log

[geirhede]

Expected Behavior
I think a core part of an authorization service nowadays is to keep track of an audit log:
Geir logged in successfully from his samsung galaxy 42
Geir removed samsung galaxy 40 as a valid device for logging in to his account
Geir failed login from device A
Geir added device A as a new client
Geir was logged out on device A because the authorization code was reused
Geir was logged out from all existing sessions because a new password was set

This log would be accessible to the user (database accessed by a service in the authorization server, for preference), along with being shipped offsite to write-only storage.

Current Behavior
There is an AuthenticationSuccessHandler and AuthenticationFailureHandler. These are awkward/impossible to use to build the above kind of audit log because the FailureHandler in particular does not keep enough information about the failure cases to be able to make a machine-parsable audit log.

I think some more provisions need to be made in the code to be able to capture this kind of logging.

I don't think it should/can live in a filter - this kind of logging needs detailed contextual information about the things that go on in the authentication providers in order to be able to gather the actionable information and send it on to some kind of audit service.

My feeling after having read through the code is that the authentication providers should be instrumented to call an abstract auditing service that users of SAS can then implement. I would like to provide a basic JDBC-based implementation of the service along with some documentation to help users make use of this feature.

Context
Being able to present an audit log to a security auditor is a core need for assessing an authentication service, see e.g. https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/ where missing logging of login and failed login is explicitly mentioned.

[geirhede]

Somewhat related ticket: #1240

[jgrandja]

@geirhede

I think a core part of an authorization service nowadays is to keep track of an audit log

I totally agree and this is critical information that should be provided from an authorization server product/service. However, Spring Authorization Server is a framework that enables these products to be built from with all the product-specific features, e.g. auditing.

Spring Authorization Server's sole focus is providing implementations of the various OAuth2/OIDC protocols. Product features are the responsibility of the consuming application/product. Some examples of product features are: UI for managing clients and authorizations, UI for removing existing consents, plugin integration with IdP's for federation, UI for access token mapping using client/user identities, logging and auditing, etc.

the authentication providers should be instrumented to call an abstract auditing service that users of SAS can then implement

There are no plans to add an Audit Service, especially because there is no standard OAuth2/OIDC specification that details this. Auditing/logging is usually very different across applications as the requirements will vary.

this kind of logging needs detailed contextual information about the things that go on in the authentication providers in order to be able to gather the actionable information and send it on to some kind of audit service

The description in this issue is very general and cannot be actioned upon. We require very specific details on the enhancement request. Having said, I'm going to close this issue. But if you are having challenges with a specific logging/auditing requirement in one of the Filter's or AuthenticationProvider's, then please log a detailed issue and we can address each one separately.