DEV Community: DID.app

Building The Best One Click Sign In

Richard Shepherd — Wed, 03 Jun 2020 11:35:56 +0000

Abstract: One click sign in using device authentication offers convenience and security to the user.

One click sign in allows users to authenticate in just one click. Delivering this was the reason DID.app was started. This is our story of implementing one click sign in.

Why do we need one click sign in?

Users have ‘account creation fatigue’. The average person already has 150+ accounts and the problem is still getting worse. There are so many websites that want you to create an account and it's hard to keep track of them all.

Users want to engage but without filling in endless forms. We also know users crave passwordless experiences by the rapid growth of password managers both in and out of the browser. Password managers simulate a passwordless sign in but only serve to paper over the root of the problem. They are cumbersome to set up a very desirable target for hackers.

How does one click sign in work?

Single factor authentication can relies on either: something you know, something you have or something you are. In a typical username and password setup, the user relies on something only they know (their password) to prove their identity. For one click sign in, we rely on something nearly ever user already has with them, their personal devices.

The user authenticates by proving they have access to a specific device. If the device is present, the user is authenticated. This is achieved with a simple cryptographic transaction between DID.app and the user’s device initiated by a single click.

Users should be familiar with this type of authentication. It works on the same principle as using as a key to unlock your front door or using debit card to pay for something. These are both forms of authentication that rely on something the users has (a key or a debit card) and are used multiple times every day.

DID.app's One Click Sign In works using cryptography. A key pair generated and stored by the device are challenged by DID.app to prove identity. The user actually has to have access to the physical device for One Click Sign In to work. Users can set up multiple devices if they regularly use more than one device. This greatly reduces the threat of account theft because hacking is only economical on scale and without actually having to steal a person's handbag.

Speed, Security and Safeguards

DID.app is focused on fast, simple and secure authentication.

Most devices today are already valuable to their owners. Most are protected by passcodes or biometric protection like fingerprint scanning or facial recognition. Devices are rarely far from their owners for long. And if one is lost DID.app makes it easy to remotely revoke the permissions the device had.

By comparison, passwords are vulnerable to phishing, guesswork and brute force. Social media accounts secured with passwords fall victim to the same threat and even some text messaging based MFA has weaknesses given that sim cards can be cloned.

No solution is perfect but device authentication is the least scalable form of account theft simply by virtue of the fact the hacker must have access to an unlocked physical device.

Finally, the best solutions recognise when a fallback may be needed. On the rare occasion the user wants to use a shared computer to access their account, One Click Sign In is not possible so DID.app falls back to magic links.

One Click Sign In Goes Hand in Hand With Conversions

One click sign in is all about convenience. Users hate creating accounts, it’s not rocket science. What’s there to love about coming up with a new password or endlessly forgetting which social network you used to sign in last time?

Convenience for the user equals conversions for your website. If you’re authenticating at all, you are looking for user engagement. Users turning away at sign up isn’t great use of marketing spend. No solution will ever induce a 100% conversion rate but One Click Sign In can help cut your losses.

There is perhaps a more pressing point than conversions. One Click Sign In is also about being respectful of your user’s time and giving them the best possible customer service experience you can muster.

Happy customers are usually easier to work with. The genuine convenience of One Click Sign In gives users a truly frictionless authentication experience. Users end up in a much better frame of mind than if they’d been sent round the houses on a whistlestop tour of their inbox, your password reset pages and back to the sign in page again.

If you would like to find out more about the technical inner workings of DID, read our ‘How DID Works’ page. If you have any questions about one click sign in, please email us: team@did.app

What is OAuth? Understanding the authorization layer

Richard Shepherd — Tue, 02 Jun 2020 15:20:34 +0000

OAuth is short for Open Authorization.

OAuth 2.0 is a framework for token-based authorization on the web. What does that mean? Basically, OAuth is a way for websites to share private information that belongs to an authenticated user of that website. Authorization tokens are issued which grants access to specific pieces of information hence the term token-based authorization.

OAuth 1.0 and OAuth 2.0 are distinctly different. When I refer to OAuth I am referring specifically to OAuth 2.0. If you would like to find out more about the differences between versions 1 and 2 you can read the OAuth entry on Wikipedia as the differences are not relevant to this article.

For example, let’s say you want to share your social media profile with a dating website. You would like the social media website to share your name, date of birth and profile image. OAuth can be used to grant the dating app access to those details on the social media website.

The framework allows the social media website to create an access token which the dating website uses to request the data you shared from your social media profile.

This method allows you, the user, to share specific pieces of information stored on one website with another website. Before OAuth was invented, if two websites wanted to share information they had little choice but to share actual login credentials and therefore share all the information stored in that account.

“Third-party applications gain overly broad access to the resource owner's protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources.”

Source - The OAuth 2.0 Authorization Framework By the Internet Engineering Task Force

OAuth is all about granting authorization to access private things. OAuth is not used for authentication. A mistake commonly made is to assume the ‘auth’ in OAuth stands for authentication.

DID.app is an authentication provider that works with the OAuth 2.0 framework helping to add an authentication layer on top of OAuth's authorization layer.

How does OAuth work?

This diagram illustrates the six steps that are taken when one website requests information from another:

By granting access, the resource owner gives the requesting website (client) to ask the authorization server for access to the resource the owner has given it permission to access.

A token is exchanged which is used to prove to the resource server that the requesting website has authorization to access the resource.

The difference between authorization and authentication

OAuth is referenced a lot when discussing authentication. This is largely because when a website authenticates a user it typically wants to give that user authorization to access protected resources such as pages on a website or images on a server.

Authentication and authorization, therefore, go hand in hand but they are distinctly different.

Authentication is the process of proving a user is who they say they are. When you visit a website to access your account you need to tell the website who you are so they can show you the right private pages and you need to prove your identity.

This can be done in a variety of ways but authentication always boils down to three factors: what you know, what you have, and what you are.

In the case of DID.app, we authenticate users by asking them to prove they have access to their email account or a previously registered device. Find out more about how DID works here.

Authorization on the other hand is the process of giving your authenticated user access to certain protected resources. So, user A might be authenticated by DID.app and the website then knows that user A is authorized to access protected resources 1, 2 and 3.

The key takeaway is that OAuth doesn’t do authentication.

OAuth’s relationship with DID.app

You will no doubt be wondering what OAuth has got to do with DID.app since DID.app is an identity provider and, therefore, primarily concerned with authentication and not authorization.

Good question. DID.app uses OpenID Connect to share authentication states between DID.app and the requesting website. OpenID Connect lets developers authenticate their users across websites and apps without having to own and manage password files. Once DID.app has authenticated the user with either email or a securely stored private key, this authentication state is shared with the website requesting it.

OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. Essentially it’s an identity layer that works perfectly with the authorization layer.

OpenID Connect uses the standard message flows defined in the OAuth 2.0 specification to communicate authentication states once the authentication has taken place.

What we learned from publishing a public roadmap and listening to users.

Richard Shepherd — Thu, 28 May 2020 14:10:50 +0000

To what extent do you allow your users and customers guide your development process? This is a question we have grappled with over the last year and, frankly, continue to debate passionately at our morning pow wow. But, today is the first time we have shipped a purely user-requested feature and it feels like a significant milestone.

For context, the requested feature allows you to start customising the appearance of DID.app’s sign in pages to ensure your authentication aligns with your brand. Here’s the feature request on our roadmap. And here’s the output in our docs.

This is a significant moment for a couple of reasons, first off, we allowed ourselves to be guided completely by our users. We probably wouldn’t have come up with this feature because we, like doting parents, believed our creation was perfect and beautiful and perfect and even more beautiful snookums, kissy kissy, oochycooo cockapoo.

And of course, we are right. Right? Actually our users helped us to see something we couldn’t see and prioritise a feature that had real value to the amazing people actually using our product.

Left to our own devices we would probably be releasing a more technical feature, such as WebAuthN integration (also on our roadmap). This will undoubtedly be an exciting feature for our audience but it would have been at the expense of what was most pressing to our users at the time. Unless you have ten dev ops on the team one simply has to prioritise one feature in front of another.

The second reason I believe this is significant is that it can be hard to ensure your vision really resonates with your audience and achieves what you set out to achieve when you’re also trying to sell it to people.

A typical prospect chat goes something like this:

Prospect: “Well sure we’d love to give your product a go and pay for it but really we need it to do X first.”

Product founder: “Sure, we can do that. Give us a week and we’ll have it ready!” - barely concealed undertones of excitement at the prospect of acquiring paying customer.

Prospect: “Splendid. Speak again in a week’s time.”

Product founder: “OK!” - hangs up. Realisation that they’ve just committed themselves to developing a niche feature that is only relevant to this one user, will take a full week of development time up and stop us from developing everything else on our roadmap.

In this scenario, your vision risks being put on hold.

Then the question arises, is your vision resonating with your audience? Do your users want what you’re making?

This one is really hard to answer. A week spent now developing a niche feature to win 1 customer might prevent you from developing a more widely adoptable feature that helps you win 10 more customers in a month’s time. This is more commonly known as ‘opportunity cost’.

I think the lesson learned from publishing our roadmap is that listening to your users at volume is the number one thing any product development team should be doing. Every user you speak to has a different opinion, a different feature idea and a different view on life but they are probably all united behind your vision to ‘change the world’.

The greater number of conversations you have, the more you can see if certain features (or variants of) are discussed. There comes a point where a feature request reaches something akin to statistical significance if you will. If this is the case and it aligns with the vision it's a perfect fit for you.

In our case, our vision is to deliver passwordless authentication on equal terms to websites and end-users in a way that respects privacy. Users requesting features like WebAuthN integration, custom styling or a Netlify guide fit well with the overall vision and these are specific requests that enable us and the user to more easily fulfill their requirements.

Something like a feature to add password auth as a fallback is completely at odds with the vision and doesn't feel right at all, even if it does mean 1 customer might come on board if we offered that feature.

Defend your vision. It’s the reason you get up in the morning and the reason you’re loyal tribe of users support you. If a feature request comes in from a new prospect that doesn’t align with your vision then think very carefully about whether the business relationship is a good fit for you.

If the feature request aligns with your vision and is just another small step along the road to the goal then go for it. Your product exists for your users.

One feature I really like about the roadmap is that users can upvote features. This seems the simplest and fairest way of putting feature development into some kind of order.

And now, our developing days are guided exclusively by our public roadmap. If it’s on the roadmap, we’re doing it. We’re excited by the way users engage with the roadmap by leaving comments and ideas. It’s really helping users get on board with our journey to achieving the vision we’re all behind and I am delighted that we have been able to take a purely user requested feature from suggestion to production now for the first time.

The first of many I am sure.

I’d love to know your thoughts on publishing public product roadmaps. If you do already, has it worked for you? If you don’t publish a roadmap is there a reason why and what is that reason?

Create buttons for 'Signing in with DID.app'

Richard Shepherd — Thu, 14 May 2020 13:16:43 +0000

Here at DID.app we are releasing our logos into the wild so you can create custom 'Sign in with DID.app' buttons on your (undoubtedly excellent) website.

This is a super-quick guide to adding custom buttons to your website.

Head over to the brand resource guidelines page. There you will find all our logo images and our icon images too.
You can copy and paste an example button. Here are a few examples to choose from (feel free to design your own too):

A light button that can be used on most pages:

<div style="display:inline-block;padding:0.3em;border:1px solid gray;margin:1em;border-radius:4px;">
  <span style="display:flex;align-items:center;">
    <img src="/icon.svg" style="height:30px">
    <span style="padding:0 1rem;">Sign in with DID.app</span>
  </span>
</div>

A block style button:

<div style="display:inline-block;padding:0.3em;margin:1em;background:#00dfc0;color:white;">
  <span style="display:flex;align-items:center;">
    <img src="/logo.svg#light-mono" style="height:30px">
    <span style="padding:0 1rem;font-weight:bold;white-space:nowrap;">Sign in</span>
  </span>
</div>

A dark sign in button:

<div style="display:inline-block;padding:0.3em;margin:1em;background:#2a454e;color:white;">
  <span style="display:flex;align-items:center;">
    <img src="/logo.svg#light" style="height:30px">
    <span style="padding:0 1rem;font-weight:bold;white-space:nowrap;">Sign in</span>
  </span>
</div>

An icon only button:

<img src="/icon.svg#light-mono" style="height:40px;background:#00dfc0;padding:0.5em;border-radius:1em;">

To turn the image into a button that triggers the authentication flow you can create a form and add your button into the html tag that handles submission.
Here's an example from DID.app's Step By Step Integration guide.

<form action="https://auth.did.app/oidc/authorize" method="get">
  <input name="client_id" value="[CLIENT_ID]" type="hidden" />
  <input name="redirect_uri" value="[REDIRECT_URI]" type="hidden" />
  <input name="response_mode" value="form_post" type="hidden" />

  <button type="submit">Sign in</button>
</form>

Feel free to reach out to me if you have any questions about our custom buttons. I can be found by emailing team@did.app

Passwordless authentication for Wordpress, here's how.

Richard Shepherd — Mon, 23 Mar 2020 12:06:56 +0000

What is DID.app

DID.app is an Identity Provider, that authenticates users by verifying access to either an email address or securely stored private key.

This allows your users to sign in with just a single click.

This guide will step you through the process of adding DID to your Wordpress website using the ‘WordPress OpenID Connect Client' plugin by miniOrange.

There is a working example website here: wordpress.did.app.

Requirements

This tutorial requires you to have Wordpress installed.

Wordpress install guide

Install the plugin on your Wordpress website

In your Wordpress admin dashboard, select Plugins > Add New from the main menu.

On the ‘Add Plugins’ page, search: ‘WordPress OpenID Connect Client’. Look for the highlighted result in the screenshot below and click ‘Install Now’. Once the app has installed, click ‘Activate’.

You can also visit the plugin’s page to download, install and activate manually if you prefer:

wordpress.org/plugins/miniorange-openid-connect-client/

Setup the App on did

You will need a DID account. Sign up to create one now.

After signing up, you will be directed to set up your first app.

Give your new app a descriptive name e.g. ‘Wordpress Demo’ and use the full URL of the website in the ‘host’ box.

DID will generate a Client ID and a Client Secret for your app. Retain this information for the next step (leave the tab open so you can come back to it).

Configure the plugin

Once activated, the plugin creates a menu option called ‘miniOrange OpenID Connect’. Click on this to start configuring the plugin to work with DID.

You will be presented with a screen which looks like this:

Scroll right to the bottom on this page and look for the option called ‘Custom OpenID Connect App’ under the heading ‘Custom Applications’. It looks like this:

Select ‘Custom OpenID Connect App’. You will now see this screen:

Complete the fields using the following values:

App Name: DID
Client ID: copy and paste this from your DID app settings page.
Client Secret: copy and paste this from DID app settings page.
Scope: openid
Authorize Endpoint: https://auth.did.app/oidc/authorize
Access Token Endpoint: https://auth.did.app/oidc/token

Make sure these options are set as follows:

Set client credentials in header: checked.
Set client credentials in body: unchecked.
Show on login page: checked.

Finally, press ‘Save Settings’.

DID’s integration with this plugin is now complete. A ‘Sign in with DID’ button now appears on the Wordpress sign in page:

Optional: Adding Login Buttons to your Wordpress Template

You can add ‘Login with DID’ buttons elsewhere on your Wordpress website using the plugin. To do this, choose the menu options: Appearance > Widgets.

In the example Wordpress theme we are using, we have been able to add a login button to ‘Footer 1’. You can add the Login button widget to any dynamic part of your website templates by selecting the miniOrange Open ID Connect widget and clicking ‘add widget’ as per the screenshot below. The exact appearance of this will vary depending on your Wordpress theme.

Optional: Login Button Styling

The ‘Login with DID’ button can be styled with some simple CSS rules. The following CSS can be used to style the button with DID’s colour scheme:

.mo_oauth_login_button {
    display: block;
    border: 1px solid #00dfc0;
    width: auto;
    text-align: center;
    background-color: #00dfc0;
}
.mo_oauth_login_button_icon {
     display: none;
}

Have a question?

If you have any further questions contact us at team@did.app.