I guess I didn’t realize how the auth flow will change when I was writing the previous message, thanks for clarification.
My concern is about how by introducing OAuth support to II, it lowers the minimum level of security, privacy and introduces a new set of problems related to that: a user can use a Google account to authenticate to II with simple password without any additional 2FA, and even with SMS confirmation there could be man-in-the-middle vulnerability, or the Google account can be phished, etc. Google has access to information about which service you use OAuth, which info you share, what’s your IP, time of requesting OAuth info/confirmation.
I like that v1 is passkeys-only and is more secure, I’m sure some part of the developers and users also like that and some apps/services might even require some minimum level of security if they are about working with some sensitive info or important/valuable data (e.g. enterprise, government, finance, journalism, activism). OAuth increases reach for some part of the audience, but I think without adding more secure alternatives you might also lose some audience who are concerned with more security or might want to build their apps/services on Internet Computer platform. And currently I don’t see how v2 address that.
If we talking in terms of standards, there is Authenticator Assurance Levels (AAL) standard from National Institute of Standards and Technology (US department of commerce) which is widely used (e.g. by Microsoft) and according to this standard using passkeys can be 2nd level (AAL2, higher is better) if user sync passkeys e.g. with password manager or iCloud, or 3rd level (AAL3) if user doesn’t sync and every passkey is a separate device or they use a hardware key. I don’t know if you are going to add OAuth check that user uses 2FA, but if not, then OAuth lowers the minimum level of security from AAL2 to AAL1 (single-factor), and even if you add that 2FA check, synced passkeys are still more secure than OAuth with 2FA.
If I was tasked to solve the problem to provide OAuth for better reach and also provide more secure options, I would propose the following solution:
- Add an option to create II accounts with different levels of security, like AAL1 (OAuth without 2FA), AAL2 (OAuth with 2FA), AAL2+ (passkeys, because detecting if user sync them or not is not trivial and you can’t be sure for certain), AAL3 (hardware keys). Or just AAL1 for OAuth, AAL2 for passkeys, AAL3 for hardware keys
- Developers can set the required level of minimum security for their app/service
- When user authenticate on the app/service with II, app/service sends the required level to user’s frontend to the II authentication window
- When user authenticate, II tells the user if the account with which they want to authenticate doesn’t have the required level and suggest to use another or create a new one with the required level. If user’s account has the required level, then II authenticate the user on the service.
- Developers also can implement check for the required level on their side, but the initial check happens when user deal with II from their frontend (without the app/service interfering)
- I think users should not be allowed to add less secure ways to authenticate to more secure accounts because, for example, it can’t be checked for certain if added passkey to AAL3 account (hardware wallet) synced or not. And an account on app/service created with higher security requirements also should somehow get to know that user hasn’t lowered security of their II account (and maybe limit access to the account).
I think this solution both allows to reach a wider audience with adding support for OAuth and also provide developers/users with more secure options for authentication.
Interesting what you and other think about my thoughts