Passwordless login

[sanjaypoyzer]

What

Let users edit their information without a password, by sending them a secure link to their email address when they want to login.

Why

The problem with passwords

Passwords are both annoying for users and rarely anymore secure than just using an email link – Arguably, it's even less secure than using an email link. This is because users often use the same password for everything, so if their password to some insecure online shop (for example) gets leaked, then also their password for a critical GOV.UK service gets leaked.

The argument against passwordless systems is usually that the email becomes the single point of defence, so if a hacker has access to your email they have access to everything. This would be true, but passwords don't protect against that as they always need a way to 'reset' them, and the mechanism to do that is basically the email link which is the passwordless system itself.

Besides this, is the point that email accounts are generally built to be more secure than the average shopfront anyway. So if it's the choice between your email account being your one way in, and a password which is shared between all the insecure websites you use, the email wins everytime.

Of course, the best way to protect an account completely is to have a unique password for every account. But we all know that users don't do this, and the more we keep getting them to remember different passwords for everything the less likely they are to make different ones. One solution is to use an app like OnePassword which stores lots of passwords for you, but that will only ever be something that more technically literate users use. Many users of GOV.UK are much more likely to use a paper password store if they do use different passwords, which has it's own security problems.

The solution

It's essentially the "Forgot your password" function, without the bit where people try and fail to remember their password.

This is already in use on GOV.UK for 'Manage your email subscriptions'.

Admittedly, this service is potentially more well suited than most to this kind of logging in as the user is starting in their email inbox anyway when they start their journey. (i.e When they realise they want to change their subscriptions.)

However, the pattern is also in use across many private sector services including Slack. (Which I believe also includes an option to create a password for quicker login, but deters users from this as a default.)

I think it would be good for more services to be experimenting with this as a login method and collecting their research findings here.

Some links to other people making this argument

• https://auth0.com/blog/is-passwordless-authentication-more-secure-than-passwords/
• https://swoopnow.com/passwordless-login/#security

[joelanman]

I believe a team at OFSTED (Register to become a Childminder) implemented something like this, I was impressed:

https://www.register-childminder.service.gov.uk/childminder/your-location/

[edwardhorsford]

We'd want to be careful with guidance around this and get input from the security community.

I think passwordless could be a good solution for some services - or offered as an alternative, but may have attack vectors we've not thought of.

I imagine it also might make accreditors wary. It's a novel interaction going up against 20+ years of established pattern (doesn't matter that it's a bad pattern). Any real-world usage as evidence for it working would be great.

There are also some downsides to passwordless that teams would need to keep in mind:

• Requires access to the email account at time of login
• Would not work for services where multiple users share an email - it's not uncommon for couples to share one email address.
• You may have access to the email, but not on the device you're using.

---

I'd personally like to see more research in this area and if GDS can give support to teams trying it. My gut is that services might offer it in addition / alongside password based login.

[sanjaypoyzer]

Of those 3 downsides:

• Access to email account is already required if you forget your password.
• What do you mean by it wouldn't work? If you mean the person who shares the email address would also have access to your account, then this is already true because of the forgotten password link being emailed there.
• This is true, but quite a rare case I would think. Most email clients have a web interface.

[peteryates]

Is it worth mentioning here that the WebAuthn specification has landed and is supported across all major platforms and browsers?

[umaar]

As a user, I appreciate the frictionless workflow a username + password combination supports: if I save my passwords in my browser (which I believe is becoming more popular due to the convenience), it will autofill those fields for me and I can log in instantly. If I have to use a magic links, it's extra overhead of having to go to gmail, wait a few seconds, reload the page a few times even it's not necessary, click on the email and finally click on the link!

I like Slack's approach of making both mechanisms available.

[adamsilver]

DfE Apply is a long application process that candidates do over days or weeks. So we need a way to let users save and come back to their application.

Starting with a traditional email/password form

Our research showed that:

• 3/9 users did not want to create an account
• 6/9 users did not understand what type of account they were creating or how it related to government. They did not know which of their GOV.UK accounts to use.
• Some users didn't know why they were creating an account

Moving to a magic link

We decided to use a magic link to make this process more lightweight and to remove the need for passwords and storage of this data.

Our research shows that:

• Some people don't know how to log back in. They don't realise they have to enter their email address, access their email and then click a further link in the email to login.

We think this is because people expect accounts to work traditionally with an email/password form.

Note: we don't feel like we have done enough realistic research on this pattern and hope to do more. So to test this, we had users create an account then we got them to imagine it was a few weeks later and they needed to do a thing that needs them to log back into their application.

Create account

Check email page

Sign up email

After clicking the link in the email you just come to the first page of the application process.

Sign in form

Sign in email

After clicking the link in the email you just come to the first page of the application process.

Original traditional login design

Login form

Create account

[a184studio]

@adamsilver or anyone. Have any new insights for a save and return feature?

Did anyone have any thoughts / investigated generating a reference number and use that to log back in?

EG, Save and exit: use XXX to come back to your claim. If this is lost you would have to ID and generate a new one. (Some how) It's an early thought.

[edwardhorsford]

@adamsilver or anyone. Have any new insights for a save and return feature?

Did anyone have any thoughts / investigated generating a reference number and use that to log back in?

EG, Save and exit: use XXX to come back to your claim. If this is lost you would have to ID and generate a new one. (Some how) It's an early thought.

@a184studio one of the early versions of the visas exemplar generated a code like that.

I'd argue that's not passwordless login though - it's a variation of credentials by another name. Its combining username and password in to a single code - presumably long enough so that it can't be brute forced.

For services where the data that would unlock is low value that seems possibly ok. But if the data is higher value, you'd want to ensure you have confidence the user using that code is the user who generated it. I think it would also be worth researching if users thought they'd need to protect that number - essentially they'd need to treat it as securely as a password.

[a184studio]

@edwardhorsford Yeah. You are right.

At present there isnt any IDV at all to make a claim. Its just so they can do it over multiple sessions if needs be.

[paulrobertlloyd]

A follow up on @adamsilver’s comment on the use of passwordless login/magic links on the Apply for teacher training service.

On the whole, we’ve found magic links to be not right for our service.

One of the main issues we’ve found is that candidates never get the sense that they have an account they can return to, just a series of different pages they’re asked to use their email to sign in with. This issue was exacerbated by the service not having a start page on GOV.UK while we were in private beta, making it difficult for candidates to find their way back to the service.

One user said:

It didn’t feel like your application was safely in your account and you could go and look at it at any time… I wouldn’t know how to find my application online if I wanted to.

Magic links also increase the amount of email communication we send to candidates – on a service that already sends a lot of different email notifications already, some of which are quite important, but can get lost in the noise.

We’ve put mitigation’s for the above issues in place (mainly around content), but as it currently stands, we’re looking to replace magic links with passwords in the near future.

[joelanman]

@paulrobertlloyd thats interesting, but it seems like a problem with people understanding they have an account, and how to log in again? Not having a start page would be a problem there as you say. Not sure I understand why the method of authentication (email link, or password) would affect the issue?

[paulrobertlloyd]

@joelanman We send periodic emails, and these include a magic link that takes them to the page in question. As such, they tend to see different parts of the service in isolation.

If we required an email/password to sign back in before seeing the page, this might reinforce the idea that they have an account, and it’s something they can return to at any time.

We’ve been calling it the elephant problem, i.e. they only ever see part of the service at a time, and come up with different ideas what they might have been looking at.

[joelanman]

@paulrobertlloyd just a random idea I had, feel free to ignore.

If we required an email/password to sign back in before seeing the page, this might reinforce the idea that they have an account, and it’s something they can return to at any time.

If the issue is with understanding that authentication/account exists, you could try linking to a login page which then takes their email address and sends them a magic link. Then you have both the advantage of not having to remember passwords, and the physical step of signing in as a reminder/explanation of an account.

[Lonli-Lokli]

So was this feature landed? I have to use Google Authenticator right now, although the best for me will be to migrate to WebAuthn+MagicLink way

[edwardhorsford]

This isn't likely relevant to government services, but I just discovered a downside of magic-link only sites:

I have a service I want to use and sign in to that I've saved to my home screen on iOS. The service is magic link only, and this means it's actually impossible to sign in. When saved to your home screen it's a separate webkit container, and you don't have access to the url bar. So whilst I can receive the magic link just fine, I can only open it in regular safari, not the home screen app.

Similar could happen if a user wanted to save a government service they regularly used - Universal Credit perhaps?

One solution could be that the page that says you've sent a link to have a text input where a user could paste the received token.

[Lonli-Lokli]

@edwardhorsford you can register your PWA as url handler https://web.dev/pwa-url-handler/

[stevenjmesser]

Does anyone have any further examples of implementing passwordless authentication successfully?

I’m working on an interesting use case where there is no personal data stored in a service but we do need to verify that a user is from an organisation. Sending a magic link in an email to an approved domain is a lightweight solution that means we don’t need to store account details.

Our users work in local authorities, therefore some of the touchpoints and channels are different to your regular GOV.‌UK transactional services – it’s a more limited user group.

[jenbutongit]

@stevenjmesser - yes 👋

For context: Although not exactly a transactional service, we have treated it as if it were: https://find-a-professional-service-abroad.service.csd.fcdo.gov.uk/find/lawyers

For a British national, who is seeking help abroad, they would use this to find a lawyer/translator/funeral director.

professionals abroad are able to apply to be on the list for a country, but the embassy/consulate (FCDO) in that country must check their credentials first in an application we call "List management".

To log into the system, yes all we do is validate the domain (that it is an fco/fcdo email address), and send an email containing the magic link. We know you are a part of FCDO since you're able to receive this email. You can only access emails if you have an FCDO managed device also.

We store the email address as the user's ID. This is all the personal information we store about them, but we will store additional information against it, like which countries/list types they should have access to.

FWIW - in terms of technical implementation, we are using JWT, and sending the token in a url that looks like https://find-a-professional-service-abroad.service.csd.fcdo.gov.uk/login?token=<token>.

[stevenjmesser]

Thanks so much, @jenbutongit. I like how you’ve avoided issues with users’ mental models of accounts as described by others in the issue. Thanks so much for sharing! I think we’ll explore this a little more and share back.

[hazalarpalikli]

Hi @stevenjmesser,

@lfdebrux and I wanted to write about how we are using passwordless login at Forms.

On GOV.UK Forms we are using passwordless login for most of our form creator users, with the help of a third party solution ((Auth0)[auth0.com]).

Form creators are civil servants, and we wanted to make it easy for users to start trying out our service, which is why we went with passwordless login. When signing in the user is asked for their email address, if the email domain is recognised as being from a central government department we then send a code to that inbox and ask the user to enter it into the browser. Our security team is happy with the security of this, as the idea is that government department inboxes should have a reasonable amount of security around them already.

Digression, our security team did require that for super-users we ensure a more secure authentication method is used, so if the user enters a GDS email address we use single-sign on with Google. This means that users in GDS just need to be signed into their work Google account to access GOV.UK Forms. Our long-term goal is to use single sign-on for all users, because that is easier than copying and pasting an emailed code, but enabling it requires connecting with the different domain services (department IT teams), and there will probably always be the email code route as a fallback.

We had to do a bit of work to make Auth0 look like the Design System. We recognised that we were limited in applying GDS styling fully as some of these changes relied heavily on javascript which is not accessible to the user. Instead we used Auth0 settings to change the material design styling such as adding crown logo, GOV.UK colours and font sizes. We weren't able to change the font type, add GOV.UK header or use GOV.UK components such as links and error messages. We tested this design and we haven’t seen any issues with users. Some of the findings were:

• Using an email code rather than a password felt different to participants, but they were all relatively comfortable with it.
• All users said they preferred the Auth0 journey.
• Participants preferred the Auth0 journey due to the simple look and feel and the numeric codes.

However David, our front end developer and DAC found accessibility issues with Auth0 HTML. We are contacting the Auth0 team to tell them about these. List of issues he identified are:

• Login page: Focusable elements fail to meet the contrast ratio of 3:1
• Login page: ‘create an account’ text doesn’t meet contrast requirements when focused.
• Login page: validation error (e.g email address in wrong format message) should be coded as a status message
• Login page: ‘User your government email address’ message should be coded as a status message
• Login page: In WCAG 2.2 AA compliant UI mode, the input’s description contains error messages even when there is no error

Create an account Alt: Screenshot from GOV.UK Forms Auth0 Sign in page using GDS colours, font sizes and crown logo.

Sign into Auth0 Alt: Screenshot from GOV.UK Forms Auth0 Sign in page

Hope this helps!

[stevenjmesser]

Thanks so much for sharing, @hazalarpalikli! Auth0 is an option we could share with our technical design authority. Another option we considered was storing a list of expected domains without storing the local-part.