Comment 2 for bug 1804042

So my original thoughts on this when bringing it up is for situations where you want to secure a service/api user with a second factor. Using totp is awkward with an automated account, and means that you'd be storing the password and secret together.

A password + source_ip limited auth could mean that your user can only talk from the given host where your automated services are running. This is also easier than trying to do token handling and totp secrets as part of automated tools and scripts.

This still doesn't really stop a malicious actor from being able to auth after gaining access to the host, but unlike the totp case, they can't take the credentials and then use them from where ever which means they have to continue using the host, and potentially have a higher chance of being spotted.

As for how to implement it, I'd push for it being an auth method because we can then do auth rules as follows:
[['password', 'source_ip'], ['password', 'totp']]

This would be easy right now right as an auth method that just needs to be explicitly defined in your auth request but actually contains just the user id.

 { "auth": {
            "identity": {
                "methods": [
                    "source_ip",
                    "totp"
                ],
                "source_ip": {
                    "user": {
                        "id": "2ed179c6af12496cafa1d279cb51a78f",
                    }
                },
                "password": {
                    "user": {
                        "id": "2ed179c6af12496cafa1d279cb51a78f",
                        "password": "super sekret pa55word"
                    }
                }
            }
        }
    }

Although adding the ability for auth methods to auto-promote themselves could also be interesting. E.g. if a user has the 'source_ip' auth method defined in rules, it auto promotes itself and is checked as part of his auth. Or some other sane auto-promotion mechanism.

Then rather than storing the CIDR for source ip checking in user options, we can keep it in credentials like totp, so the the MFA pattern of keeping 'secrets' in credential stays more consistent (not that CIDR is technically a secret).