We also should not forget to update these hook documentation pages once the change is merged.

• AbuseFilter: uses AbortNewAccount and AbortAutoAccount to prevent account creation based on rules. Should be a pre-auth provider.
• AntiSpoof: uses AbortNewAccount to prevent creation of users with names similar to an existing one. Should be a pre-auth provider.
• CentralAuth: already audited in T91303.
• CheckUser: already audited in T91303.
• ConfirmAccount: adds a special page to request accounts. Uses AbortNewAccount to disable normal account creation in case of name conflicts with pending requests. Also tries to reuse captchas from the normal signup page on its special page (or not, depending on settings). Sould become a pre-auth provider.
• ConfirmEdit (aka FancyCaptcha): injects captchas on login and registration pages, uses AbortNewAccount and AbortLogin to verify them. Should be a pre-auth provider.
• CryoKey: uses UserLoadFromSession to authenticate the user via some combination of a browser extension and a JSONP call, but only if a query parameter is set. Seems like a somewhat roundabout way to do authentication via a redirect flow. Should probably be a primary authentication provider.
• LdapAuthentication: already audited in T91303.
• MediaWikiAuth: already audited in T91303.
• NewSignupPage: uses AbortNewAccount to prevent registration if the terms of use is not accepted. Should be a secondary auth provider, maybe?
• NewUserMessage: uses AuthPluginAutoCreate to post welcome messages. Should use LocalUserCreated instead.
• OATHAuth: adds and extra field to login and uses AbortLogin to verify it. Should be a secondary auth provider.
• OAuth: uses UserLoadFromSession to authenticate based on the presence of HTTP headers. Should be a session provider.
• OAuthAuthentication: uses AbortNewAccount to disallow local account creation. Since it also does remote authentication via OAuth, it should just be a primary auth provider.
• OpenStackManager: already audited in T91303.
• Phalanx: uses AbortNewAccount to prevent registration based on blacklists. Should be a pre-auth provider.
• PluggableAuth: uses UserLoadFromSession to replace MediaWiki authentication with its own plugin system. AuthManager can probably replace it as long as its plugins can be converted to providers (-> need to audit extensions using PluggableAuthUserAuthorization hook), except that it can also log out on inactivity which AuthManager does not support currently (see the related bullet point in the longish comment on the AuthManager skeleton patch).
• SecureSessions: saves IP/useragent in session and uses UserLoadFromSession to evict the user if it changes. Uses UserSetCookies to persist those values. Uses AbortLogin for some unrelated checks (like allowing the user to set a country whitelist). That last part could be a pre-auth provider; not sure the rest fits into AuthManager currently. (But it should, IMO; see comment on PluggableAuth. Maybe we need some kind of pre-session-provider.)
• SemanticSignup: already audited in T91303.
• SpamBlacklist: uses AbortNewAccount to prevent account creation based on a blacklist. Should be a pre-auth provider.
• SSLClientAuthentication: uses UserLoadFromSession to authenticate from request data (client-side cert), and AbortLogin to explain why the user is not logged in after a successful passsword-based authentication, if the user has an invalid cert and the extension's UserLoadFromSession takes precedence over normal login. This is a use case we should consider for AuthManager (what happens if you make a successful login but the authoritative session provider is immutable? how do you communicate failure reason from a session provider?). Apart from that, the extension should become a session provider. It also sets login cookies on successful auth; AuthManager currently does not support that.
• TitleBlacklist: same as SpamBlacklist.
• TwitterLogin: already audited in T91303.
• TwoFactorAuthentication: light version of OATHAuth, same applies.
• UserThrottle: uses AbortNewAccount to throttle account creation. Could be a pre-auth provider, but probably historical, core can do that. (Seems like it was deployed on WMF clusters at one point, then undeployed, which supports that.)
• WebPlatformAuth: turns MediaWiki into an authentication provider, by mirroring the session into memcached on UserSetCookies. (Probably so that a website on the same domain can use the MediaWiki cookies to authenticate?) Probably could be done by subclassing the cookie session provider, although it seems a pretty broken idea to begin with.

What should AbortNewAccount be replaced with and shoulden the hooks pages be updated with deprecation notices and how to migrate the code to the new hooks.

@Paladox: Why you reopened this task? *wondering* The hooks can be "replacced" by converting the extension into an Authentication provider (secondary or primary). This would be part of the AuthManager migration, tracked in this task (and associated): T89459: Modernize MediaWiki authentication system (AuthManager)