CookieSessionProvider is optimized to be used with a password-based provider, and even for that it has a bit of legacy cruft. It sets six cookies: <wiki>_session, <wiki>UserID, <wiki>UserName, <wiki>Token (for the "keep logged in" option), <wiki>LoggedOut (for cache breaking) and forceHTTPS. CentralAuthSessionProvider extends this with four more cookies, centralauth_Session, centralauth_User, centralauth_Token, centralauth_LoggedOut. It's a bit over the top even for our current authentication flows; once we move authentication off the wiki (T348388: SUL3: Use a dedicated domain for login and account creation), we won't need most of these.

We should probably create a simpler session handler for wikis which use a remote identity provider, maybe split in a core and a CentralAuth part like CookieSessionProvider / CentralAuthSessionProvider. (Or maybe we should just figure out how to bring the central session concept into AuthManager.) Probably just needs four things:

• The session cookie, always per-wiki (since we use it to store session data like CSRF which is also per-wiki). Maybe we don't even really need this and can just use a hash of the central session ID? We'd have to rethink how ID reset works though.
• A proof-of-central-login token, which can be confiugred to be set on the parent domain. CentralAuthSessionProvider uses a separate central session id + central user token cookie. We can do that, but if we can make the "are we centrally logged in" check unobtrusive enough, maybe it's not really needed.
• The logged-out cookie, and forceHTTPS for non-Wikimedia wikis; these can also be set on the parent domain.