Allow authcookie to be used from a different IP address + extra features
Fusl
First of all, authcookie's should not be bound to a single IPv4/IPv6 address as this would cause several issues with the VRChat client when the IP address changes. Users are still able to join instances through the friends list due to the Photon servers not verifying the authcookie but stuff like the friends list doesn't refresh and shows old information until the client is restarted, at which point a re-login is required since that authcookie seems to be the only thing that VRChat stores across restarts, which also causes users to pick less secure passwords (because who wants to type in a 20 character password with special characters every time they need to restart their game due to this limitation?).
I do understand that implementing this would cause a security risk to be added to the entire system as authcookies can be stolen, even through other means than just a VRChat security hole, so extra steps need to be implemented to counteract against this risk:
authcookie's should be "dynamic" bound by default, which means they can be used from any IP address if at least one or multiple of many comparison factors are met: Country where the IP address is assigned in according to it's whois, AS number of the IP address, Cloudflare datacenter and/or location the traffic has passed through, HWID if it's from the VRChat client or User-Agent if it's from a browser. If too many comparison factors fail the check, the client needs to reauthenticate.
Once the client re-uses that same authcookie multiple times on different days with the same IP address, the authcookie turns into a "static" bound one which means it gets rejected when trying to use it from a different IP address, HWID/User-Agent, etc. than the one it is bound to or when at least one of the other comparison factors fail (other than the Cloudflare DC/location which should just be a fallback check for the dynamic bound option).
Additionally, authcookie information, the bound type and which IP address or IP addresses each authcookie was used and at exactly what timestamp it was used, should be exposed directly to the user, at least through the website, and the user should be given the option to expire a certain authcookie through a single click operation as well as set the expiration time and force reauthentication time for authcookies (expiration time = expire when not used within X days; reauth time = force reauthentication, even on valid authcookies).
Log In
Aev
System
These are all really good recommendations!
Auth Tokens being tied to IP is an old decision - it replaced an earlier behavior (Token expires after a relatively short time and cannot be renewed) which was also wildly inconvenient for the user - but we've always operated on the presumption that SOMEBODY is going to figure out how to steal tokens in client-land, _someday_, and when they do we need Additional Security Measures to shut that down.
IP is (as you've noted) a painfully, uh, broad security measure, and we could improve it dramatically by using more comprehensive and subtle angles to try to suss out a stolen token (and allow users to audit their own recent sessions). We've had similar discussions to this on our internal channels, and come to similar conclusions.
Fusl
System: With the recent implementation of instance join tokens and IPv6 becoming more popular this is becoming an even worse and more annoying issue. Is this still something that's in consideration and going to be implemented any time soon?