I just went to log in to the Mondo developer portal, and was disappointed in the UX of the login flow.
The best case scenario for this flow is something like:
Enter email.
Switch to email client.
Click link in email.
Use developer portal.
However, the worst case scenario is much worse:
Enter email.
Go to webmail (no email client set up)
Enter email.
Enter password.
Wait for 2FA SMS.
Enter 2FA code from phone.
Wait for email.
Copy link in email.
Paste into the browser you want to use (maybe not default).
Use developer portal (or other 3rd party application).
Imagine this on an unstable and slow mobile connection, or imagine a situation where you don’t access the email address directly, but have a series of redirections applied (I do this), the email could take 5 minutes to arrive, resulting in a pretty bad user experience. I realise this might be for the minority of users, but I think it’s worth considering. This experience would be much worse than most other online banking, and I don’t think that should be the case with Mondo!
I understand that security is of paramount importance, but I’d much prefer that to be through standard 2FA channels, like SMS or Google Authenticator, paired with a password.
With this, the worst case scenario would be:
Enter email.
Enter password.
Enter 2FA code.
Use application.
The best case scenario could eliminate steps 1 and 2 with something like LastPass.
Why was this flow chosen? What are the advantages? And is it possible to have a discussion about whether this is the desired user experience?
Not entirely happy with the login flow either, especially since by the time I actually receive the email (sometimes 15-30 minutes later), the link has sometimes seemingly expired with an unhelpful error message both on the web and in-app.
SMS I’d mostly avoid due to the difficulty of receiving when overseas and the relative ease that a phone number can be stolen or SMSes hijacked. Also remembering that SMS and Emailed codes are vulnerable to being one-time phished too. (Something U2F avoids, though is not widely implemented outside of Google and currently fails on mobile.)
I can see why this login method was attempted, I’ve tried it myself on various projects but it relies on a series of unknown 3rd parties working well and securely together in addition to the issue of people being trained to click login links in emails with no verification of the sender.
Hey Dan. Sorry to hear you’re having a hard time logging into the developer portal.
I have to admit that we haven’t put very much time into polishing the login flow for third-party apps (our developer portal uses the same flow as other OAuth apps). It’s very much another instance of our “ship an Alpha and refine from there” way of working , though maybe we shipped it too early in this case.
Sorry this reply is a bit long, but here’s some of the things that went into our thinking about password-less sign in:
Having passwords means you need some mechanism to reset a password when a user forgets it. These mechanisms usually rely on sending an email, which means that the security of an email account would still be critical to the overall security of a user’s Mondo account.
Attackers are likely to be very motivated to access a Mondo account; the rewards for doing so are potentially huge.
What we’ve done so far is very much a first step. However, I’d personally like us to try to solve the problems with password-less sign-in without introducing passwords back into the mix.
One of the things we’re thinking about is removing the “email” step entirely for web-based logins. Instead, the flow would be something along these lines:
A third-party app (or our developers portal, which shares the same flow) redirects the user to auth.getmondo.co.uk
The user enters a piece of information identifying them into the web form (in this case, probably their email address)
A notification is dispatched to the user’s phone
The user opens the notification on their phone and sees details of the app that would like to access their Mondo account
Assuming the user approves the request, they return to their computer where their web browser redirects back to the third-party application
So the only scenario in which the user would need to receive the login email is when they sign-in on their phone – and we intend users to be permanently signed in to the app, just like Facebook, Twitter, etc.
Do you think this flow would help? I’m keen to hear your thoughts.
The OAuth device flow (currently in draft) describes scenarios for authentication on devices that don’t have easy data-entry means so authz/authn is delegated to a second device. I think this actually can result in a really nice UX for 3rd party clients by making use of an official 1st party app.
WhatsApp for web (http://web.whatsapp.com) has got a nice implementation of this; you scan a QR code on a web page using the mobile app and you’re immediately given access on the web.
Sounds good, passwords are terrible but this mostly just shifts responsibility to the email provider, though they have always been responsible considering that you can just do a password reset.
You could go further and remove the email address entry requirement on the web by just throwing up a QR code to scan on the phone (consider using iOS’ lovely APIs for this). LINE also uses QR codes like WhatsApp web as @alexbilbie mentioned, it’s a VERY popular authentication method in Asia (especially China, South Korea and Japan in my experience) where most things are mobile first and desktop computers are shared and not trusted for security (think internet/gaming cafes, work computers, etc.). Of course, email link fallback should always be available in cases where the user has lost their phone, etc.
By using QR codes, you avoid email problems, key logging, phishing (including OTP phishing), you require the phone to be unlocked and present without allowing somebody to create app notification spam by entering another user’s email address.
While it could certainly be refined, here’s what logging in to LINE for Mac with a QR code using LINE for iOS looks like. Note that LINE also uses QR codes for adding friends and official accounts and desktop isn’t a priority for them so login is kind of tacked on to that. Confusingly, if you were going through the normal app UI, you would go to add friends(?!), then by QR code.
Thanks for the reply, loads of detail, it’s really great to see the thought that’s going into these decisions.
(our developer portal uses the same flow as other OAuth apps).
Just to clarify, this was my reasoning for raising the issue. I don’t mind how I log into the developers console, I’m really concerned with the UX of logging into third party services. I see the market of third party services as crucial to what Mondo is doing, as it’s one of the key differentiators between Mondo and the normal high street banks. This is why I think the UX is so important.
All your points about passwords are completely valid, I agree that passwords aren’t used well by the majority of users, and that 2FA isn’t widely used. However, I would encourage Mondo to:
Allow those users who want this additional security to use it, i.e. not penalise users who know how to work securely.
Educate users as much as possible about security.
The flow you describe with the Mondo app being used for 2FA would be a significant improvement over email-only based auth I think, especially given the permanently authenticated app. A fallback to email would be useful too, but not necessarily high priority.
Sorry if this is resurrecting an old thread but I wanted to add to the request for an OAuth flow without the email step. I am working on an application that requires data is passed back to it via a url handler in the original webview it opens. So opening a link from the email breaks this flow. However something like what Oliver suggested above with a mobile push notification would work.
, though maybe we shipped it too early in this case.
to this.