I've spoken to Steve Osguthorpe 

It's been a while since he investigated this. He provided me with starting point (for defining users and logging in) that I think we can use:

"mod-users-17.2.3"
"mod-configuration-5.5.0"
"mod-permissions-5.12.2"
"mod-login-7.1.1"
"mod-pubsub-1.3.3"
"mod-circulation-storage-12.1.4"
"mod-inventory-storage-19.4.4"
"mod-password-validator-1.8.2"
"mod-authtoken-2.6.0"
"mod-event-config-1.6.1"
"mod-template-engine-1.10.2"
"mod-email-1.9.2"
"mod-sender-1.4.0"
"mod-notify-2.7.1"
"mod-users-bl-6.1.1"
"mod-patron-blocks-1.1.4"
"folio_users-5.0.9

The versions of pre-2021 R2. I think the list seems about right to me.

The UI handles auth-n in @folio/stripes-core, not @folio/users; it directly relies on users-bl, authtoken, and configuration. Due to packaging @folio/stripes-smart-components within @folio/stripes, there are also dependencies on notes, tags, and password-validator; these should be made optional interfaces with a minimal amount of effort. 

It looks like we could significantly prune the dependency tree if we rewrote authentication directly in terms of login (depends on users), authtoken (depends on permissions, users, both pure), and configuration (pure) instead of in terms of users-bl which requires users, permissions, login, service-points, service-points-users, password-validator, authtoken, notify, and configuration . 

This would also make that "minimal" platform significantly/completely library-agnostic, which I think would be a major win from the point of view of FOLIO as a generic application development platform rather than as a library application development platform.

Starting with the snapshot-backend-core Vagrant image, I was able to pare things down to six services, plus okapi, and still send a successful authentication request:

vagrant@vagrant:/etc$ docker ps --format '{{.Image}}'
docker.ci.folio.org/folioci/mod-authtoken:2.9.0-SNAPSHOT.91
docker.ci.folio.org/folioci/mod-permissions:5.15.0-SNAPSHOT.116
docker.ci.folio.org/folioci/mod-users:18.1.0-SNAPSHOT.165
docker.ci.folio.org/folioci/mod-login:7.5.0-SNAPSHOT.98
docker.ci.folio.org/folioci/mod-login-saml:2.2.2-SNAPSHOT.74
docker.ci.folio.org/folioci/mod-configuration:5.8.0-SNAPSHOT.94
folioci/okapi:latest
vagrant@vagrant:/etc$ curl -v --location --request POST \
  'http://localhost:9130/authn/login' \
  --header 'x-okapi-tenant: diku' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "username" : "diku_admin",
    "password" : "*****"
  }'

[...]
* upload completely sent off: 55 out of 55 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 201 Created
[...]

This was a first step with minimal effort, just shutting down modules until auth-n failed and it was really easy to show here. It'll take some Real Work to get the UI running because it'll have to be refactored away from bl-users/login?expandPermissions=true&fullPermissions=true  to authn/login. That means not only a different login-endpoint but also an additional query to get the user-data (authn/login for some reason returns the username and password (?!?) instead of a user-id). It shouldn't be a huge effort, but it's bigger than just flipping some modules off.

This is really great progress. Is there any way to avoid the dependency on mod-login-saml? SAML-based SSO support seems a strange requirement for a minimal platform.