I just formed a strong opinion, so I apologize if this comes across as if I know something in the area. I think the warning is key here: [image: image.png]
And in reality the WebOTP verification of phone numbers is actually a work around for establishing client access via the real AS which in this case would be the phone number provider. The fact that then there is even a standard being developed on top of the hack workaround which in itself is known to be a security risk, is shocking. Rather than coming up with this, I would rather the phone os developers just write phone side AS plugins to support push notifications from providers uniquely identifying the device, rather than the phone number. That would avoid the need to have a number, provide a mechanism that works when "online" but not connected to the provider (i.e. in a different network), and allow all AS connect to the user without needing a custom 3rd party app instead specifically for the AS (or a generic one that lacks good UX) for every new app a user wants to enable MFA using their device. Magic links are certainly better if they don't register the device, and in the case device persistence isn't a requirement, then jwt bearer grant certainly works a good solution, doesn't it. Even with phone numbers you can still send the link and click on it, thus sidestepping the justification in the document about, since the SMS is a full link: > Then copying and pasting it to the form is cumbersome I'm probably missing ten different important nuances here though. - Warren Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Wed, Mar 3, 2021 at 10:15 PM Sam Goto <goto=40google....@dmarc.ietf.org> wrote: > Unclear to me if this is a perfect fit for the question, but wanted to > raise awareness of WebOTP [1] which is coming up with conventions for > verifying phone numbers (e.g. with SMS OTP formats [2]) and email addresses > (e.g. conventions over magic links). > > LMK if that's of interest/relevance and I'd be happy to expand. > > [1] https://web.dev/web-otp/ > [2] https://github.com/WICG/sms-one-time-codes > > On Tue, Mar 2, 2021 at 12:10 PM Evert Pot <m...@evertpot.com> wrote: > >> Thanks Neil & Hans, >> >> Our AS doesn't do jwt quite yet. It's in-house, but open source. We don't >> have rfc7523 yet, but this does sounds like a pretty great longer-term >> solution. >> We're a bit time constrained, so perhaps this feature just needs to be >> done as a one-off before we can do RFC7523 for real, later. >> >> Thank you! >> >> On 2021-03-02 3:05 p.m., Neil Madden wrote: >> >> One option is JWT Bearer grant with “jti” and replay prevention ( >> https://tools.ietf.org/html/rfc7523#page-7 >> <https://tools.ietf.org/html/rfc7523#page-7>) if your AS supports it. >> This is nice if some other component is generating the emails as it needs >> no coordination with the AS. >> >> — Neil >> >> On 2 Mar 2021, at 19:04, Evert Pot <m...@evertpot.com> <m...@evertpot.com> >> wrote: >> >> >> >> Dear list, >> >> We have a requirement to let users log in to an application via a code >> sent by email. >> This code needs to be exchanged for an access/refresh token pair, and >> should only work once. >> >> The access/refresh token scope would give limited access to the >> application. Since we already use the authorization_code flow for other >> (more sensitive) parts of the application, I would like to re-use the >> OAuth2 framework for parts of this. >> >> It doesn't sit right with me to overload the 'code' in >> authorization_code, so I was considering introducing a new custom >> grant_type for our application, specific for this purpose. >> It seems that grant_type in the 'token' endpoint would support extension >> in this manner, by using a uri such as https://vendor.example/email-token >> >> I'm comfortable implementing this, but curious: >> >> 1. Is there already some prior art that I'm not aware of? I'd rather >> not do a custom grant_type if there's something standard I could do. >> 2. Are there any major pitfalls associated with this? >> >> Evert >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
