3 ms·

It would simply not handle pretty much any case that I have used OAuth2 to implement so far. For example - login system that merged LDAP/Kerberos/client cert/l

by p_l 4y ago

It would simply not handle pretty much any case that I have used OAuth2 to implement so far. For example - login system that merged LDAP/Kerberos/client cert/long-lived application token authentication into single system, that also linked said authentication system into all applications in the network, including making it possible to login to AWS Console using Kerberos (that one was twisty to get running, not because of OAuth2 but because of how it is handled by AWS IAM). Also, I have used it to link in MFA systems of different kinds (it was definitely easier side than industry standard of using Radius) In addition, this proposed system requires that every app has ability to send emails, which honestly is less simple than it sounds, especially today when sending to arbitrary public emails.

klabb3 4y ago
For service accounts, email is clearly not the right choice. I don’t have experience with enterprise auth, are Kerberos etc not using company email for human identity? > this proposed system requires that every app has ability to send emails, which honestly is less simple than it sounds For humans and especially end-users of consumer services, my observation is that the elaborate auth dances are using email ownership as last resort anyway, ie for account recovery and/or a trusted 3p that has verified the email. So the thought is simply to make that flow more convenient. Perhaps this is misguided.
- p_l 4y ago
  In case of OAuth2/OIDC, if I do not use external providers (like Google etc.), I can still deploy one of the many OAuth2/OIDC providers myself and centralise handling of user database this way. This also means I have one place to support sending last resort emails As for enterprise auth, a lot of places in fact do not use emails for identity. Sometimes there's more than one login id mapping to one identity (noticeable case - Kerberos/LDAP as done by Active Directory, where your login can come in email-style form and pre-AD form, and the email-style one doesn't have to correspond to an email)

by p_l 4y ago

klabb3 4y ago

For service accounts, email is clearly not the right choice. I don’t have experience with enterprise auth, are Kerberos etc not using company email for human identity? > this proposed system requires that every app has ability to send emails, which honestly is less simple than it sounds For humans and especially end-users of consumer services, my observation is that the elaborate auth dances are using email ownership as last resort anyway, ie for account recovery and/or a trusted 3p that has verified the email. So the thought is simply to make that flow more convenient. Perhaps this is misguided.

p_l 4y ago
In case of OAuth2/OIDC, if I do not use external providers (like Google etc.), I can still deploy one of the many OAuth2/OIDC providers myself and centralise handling of user database this way. This also means I have one place to support sending last resort emails As for enterprise auth, a lot of places in fact do not use emails for identity. Sometimes there's more than one login id mapping to one identity (noticeable case - Kerberos/LDAP as done by Active Directory, where your login can come in email-style form and pre-AD form, and the email-style one doesn't have to correspond to an email)