It might look trivial, though this is not a simple case...
Basically, all you need to do is to create a (Spring) Filter
in your webapp, that will catch all requests, and by the subdomain of the referrer it will decide what authentication method to use (it can be achieved by a simple table in the DB, that will map a subdomain to an enum, e.g. 'oAuth', 'SAML', 'local', etc. This Filter should be placed before any other authentication filter, and as I said , it will technically decide which auth method to use.
I had to tackle this kind of scenario, and the best solution - as far as I think - was to support one authentication method, and then creating a "bridge" to other authentication methods, as needed. For example, the main authentication method is oAuth2.0. Then, in cases where you need other types of authentication, you create "adapters", or "bridges", to the other mechanisms. So if you need to support LocalDB for cusomerB, and AD for customerC, then you adapt from oAuth to localDB or to AD. In my case, I had to support SAML, so I've created a bridge from oAuth to SAML, because it is not trivial for the same Spring-app to support both oAuth and SAML. (Supporting AD and LocalDB from oAuth are much easier, I think.)
How it happens? you wrap your local DB to be an oAuth-provider, so your app will connect to it. and the same for your AD-connector. You have to parse the URL that the user enters, and you get the "tenant". Then you go to your DB, where you map from the tenant to the needed authentication mechanism, and you know what "bridge" to use.
HTH.