> It's hard to keep up with what's legitimate when seemingly everything you do involves a different domain with a different design language and account management process.
This is so true. When you have app.<appname>.tld, <appname>app.tld, app.<appname>app.tld, cdn.<appname>.tld, cdn.<appname>app.tld, <appname>cdn.tld, <company>.tld, <appname>.<company>.tld, <company>corp.tld, etc, it's difficult for even tech-savvy users to spot fake domains, especially since there can be multiple TLDs used with seemingly no consistency. Then someone comes along and registers <cornpany>.tld, <company>.othertld, or <compаny>.tld (the "а" is a cyrillic "a")...
Even if you try to integrate Oauth so you can tell users "only enter your username/password on auth.<company>.tld", it's not always consistent. Google will require your email before redirecting, some services require an email and a password (whether it's correct or not) before redirecting, others have special company-specific subdomains, and I've seen a couple where you have to click on an SSO link on the login page and type in your company's domain. Then you get services where you type in your username/password into their site and it authenticates through AD or another backend mechanism which never goes through your Oauth flow (my college had O365 setup like this), bypassing 2FA and defeating the "only auth.<company>.tld is trusted" message.
The best solution I've seen for all of this is an internal TLD, but that requires a VPN to access from offsite, you have to maintain your own CA and DNS (which a much greater impact when it goes down), some services will not allow Oauth redirects to them, and it only works for internally hosted applications.
This is so true. When you have app.<appname>.tld, <appname>app.tld, app.<appname>app.tld, cdn.<appname>.tld, cdn.<appname>app.tld, <appname>cdn.tld, <company>.tld, <appname>.<company>.tld, <company>corp.tld, etc, it's difficult for even tech-savvy users to spot fake domains, especially since there can be multiple TLDs used with seemingly no consistency. Then someone comes along and registers <cornpany>.tld, <company>.othertld, or <compаny>.tld (the "а" is a cyrillic "a")...
Even if you try to integrate Oauth so you can tell users "only enter your username/password on auth.<company>.tld", it's not always consistent. Google will require your email before redirecting, some services require an email and a password (whether it's correct or not) before redirecting, others have special company-specific subdomains, and I've seen a couple where you have to click on an SSO link on the login page and type in your company's domain. Then you get services where you type in your username/password into their site and it authenticates through AD or another backend mechanism which never goes through your Oauth flow (my college had O365 setup like this), bypassing 2FA and defeating the "only auth.<company>.tld is trusted" message.
The best solution I've seen for all of this is an internal TLD, but that requires a VPN to access from offsite, you have to maintain your own CA and DNS (which a much greater impact when it goes down), some services will not allow Oauth redirects to them, and it only works for internally hosted applications.