Forem: Richard Shepherd

How to style HTML buttons with CSS for your website

Richard Shepherd — Tue, 15 Mar 2022 17:56:34 +0000

Learn how to create a simple button out of a link tag and style it with CSS that will work on any website.

CSS Buttons are a great way to add clickable buttons to your website because they are responsive (adjust to different screen sizes), much faster to load than buttons made with image files and you can add effects to CSS buttons like ‘hover’ and ‘focus’.

Now you’re convinced you definitely want HTML Buttons styled with CSS on your website, let’s look at how to actually make them.

Step 1 - Creating a HTML Button

The first step is to create some HTML that you can then copy / paste into your website to actually create the element that is going to be your button.

Buttons can perform many different functions on a website but let’s assume that you want your button to take a user to another page on your website. For this we need to write a link:

<a href="https://html-buttons.com/button-generator">Click me! I'm a button.</a>

Clicking this link simply takes the user to the page defined inside the quote marks. Links are made by using an opening and closing anchor tag: <a>Click Here</a>. The href=”” attribute defines the location of the link.

We now have a basic HTML link that looks like this:

Click me! I’m a button.

We can now use CSS to turn it into a stylish button.

Step 2 - Using CSS to style the HTML Button

To style your button with CSS we need to add a class to the link tag. You can call the class pretty much anything you like but let’s go with ‘myButton’ for this demo.

<a class="myButton" href="https://html-buttons.com/button-generator">Click me! I'm a button.</a>

The class allows us to ‘target’ the HTML with our CSS to give it style. To do this we need to create a stylesheet and define the CSS rules for our new class ‘myButton’.

Stylesheets are defined in HTML with the <style> tag with all your CSS is written inside the style tags.

<style>
/*Your CSS goes in here*/
</style>

To define the class ‘myButton’ add the following code inside your new style tags:

<style>
  .myButton {
     /*CSS rules are defined in here*/
  }
</style>

Note how the class ‘myButton is preceded by a fullstop and followed by an opening and closing curly bracket.

We will write our CSS rules inside the curly brackets.

Step 3 - Getting creative, styling the new CSS Button

Everything is set up, we can go ahead and get creative to turn our plain old HTML link element into a beautifully styled CSS Button. But what kind of style should it have?

There are no rules, you can style your button however you like. Here are a whole load of CSS styled buttons for inspiration and below are my ideas for styling a good button.

If you don’t want to write your own code, you can also check out the button generator I made which allows you design buttons visually without coding.

Spacing

Spacing sets buttons apart from other elements on the page and it’s useful to give us space around the words inside the button so that we can add a colored background or a border later on.

There’s a tiny problem we need to solve first. Anchor tags are by default ‘inline’ which means they display themselves inline or ‘inside’ other html tags, most commonly paragraph tags.

To fix this we want to change the display property for the anchor tag to ‘inline-block’. This then allows us to add spacing in the form of ‘padding’ to the button. Here is what that code looks like and the result. I’ve also added a light border to you can see how the padding has increased the size of the button.

<style>
.myButton {
     display:inline-block; /*This ensures the button stands out from other HTML elements*/
     padding:20px; /*This adds 20 pixels of padding around the inner text on all sides*/
     border: 1px solid gray; /*This adds a light gray border, 1 pixel wide, around the outside of the button*/
}
</style>

Here’s the result of the CSS above on the HTML anchor element:

Color

A splash of color makes any button stand out. Often designers come up with ‘accent’ colors in their brand designs and these are perfect for buttons.

Usually, the accent color used in a button is opposite the site’s main theme color so that it stands out nicely. For example, orange buttons work well on blue websites.

Let’s add some color now to our CSS Button. We can add color to the button in three main ways:

Background
Font
Border

These parts of your button can be colored by adding the following CSS:

<style>
.myButton {
   background: orange;
   color: blue;

   /*CSS rules already written*/

   display:inline-block;
   padding:20px;
   border: 5px solid green; /*Note how I changed the color from gray to green*/
}
</style>

Here’s the result of adding those new color rules:

Ok, so it’s not going to win any design competitions but at least we know the CSS works!

CSS recognises loads of colors by their names (i.e. red, orange, blue, yellow etc) but you can also define colors using Hexidecimal which gives you many more possible colors to choose from.

Hex colors (short for Hexidecimal colors) look like this: #21BC27 which just happens to be a rather nice shade of green.

The easiest way to choose a Hex color is to use a color picker like this one.

Once you’ve found colors you like, you can use the Hex values in your CSS like this:

<style>
.myButton {
   background: #21BC27;
   color: #CDFFCA;

   /*CSS rules already written*/

   display:inline-block;
   padding:20px;
   border: 1px solid #20750D; /*The new border color is here*/
}
</style>

And here’s the result of those Hex colors. Certainly a more pleasing button than the first attempt.

Borders

Borders are very useful when styling HTML and CSS Buttons because not only do they give your button an outline that can be colored and styled but they also allow you to define what happens to your button’s corners.

Do you prefer rounded corners or hard square corners? We can use borders to give us both.

Borders are defined in two main rules, the ‘border’ rule and the ‘border-radius’ rule. The ‘border’ rule allows us to define border width, border type and border color on one line and the border radius rule allows us to define the radius of the corner. That is to say, how rounded the corners of the button should be.

Here’s what that looks like in CSS and in the resulting button.

Note how I removed the old border rules and replaced them with new ones:

<style>
.myButton {
    border: 5px solid #20750D;
    border-radius: 12px;

    /*CSS rules already written*/

    background: #21BC27;
    color: #CDFFCA;
    display:inline-block;
    padding:20px;
}
</style>

These new border rules create a solid border on all sides of the button 5 pixels wide in dark green (#20750D). All four corners of the button are rounded to a radius of 12 pixels. Here’s the result:

There are loads of options with your borders. For a start, you don’t have to have a border on every side. You can define a different style for the top, right, bottom and left border of your button. You can do the same for the corners too so none of the sides or the corners have to be the same.

Here’s how that looks in CSS:

<style>
.myButton {
    border-top: 5px solid #20750D;
    border-right: 2px solid red;
    border-bottom: 10px solid yellow; 
    border-left: 7px solid green;
    border-radius: 12px 1px 8px 30px;

    /*CSS rules already written*/

    background: #21BC27;
    color: #CDFFCA;
    display:inline-block;
    padding:20px;
}
</style>

Notice how we define border-top, border-right, border-bottom and border-left separately but the border-radius values are all defined on one line. When you’re defining multiple values on one line the order is always top, right, bottom left. However, with corners it’s top-right, bottom-right, bottom-left, top-left.

Here’s what the button now looks like:

Pretty awful! But, it demonstrates the point. One button design that makes good use of different border values is Forest. Forest has one dark green border at the bottom until you hover over it when you can then see light green buttons on the other three sides.

Seville on the other hand has a consistent border style all the way around but uses different border radius values to create a unique look with opposing corners rounded and square.

Borders also don’t have to be solid. They can be:

solid
dashed
dotted
double
groove
ridge

Here’s how to write CSS for the different border types:

<style>
.solid {
   border: 2px solid gray;
}
.dashed {
   border: 2px dashed black;
}
.dotted {
   border: 2px dotted green;
}
.double {
   border: 2px double blue;
}
.groove {
   border: 2px groove yellow;
}
.ridge {
  border: 2px ridge red;
}
</style>

Each border type looks totally different:

Groove and Ridge border types only really work visually when the border color is light enough that the contrast can be seen. If you use a very dark color, the effect isn’t visible.

Hover Effects

Hover effects change the button’s style when the user hovers their mouse or cursor over the button. Note that hover effects don’t really work on touch devices where there is no cursor.

However, everyone loves a hover effect on a button because it makes the button interactive and helps reinforce the point that the button should be clicked.

Any of the CSS we’ve added so far can be changed with a hover effect: spacing, color and border, but you there is also another favourite of the hover effect styles: opacity.

Opacity is the level of ‘see through’ the button is. You can make any element more or less see through on the page or hide something all together. The opacity rule looks like this:

<style>
  .opacityButton {
    opacity:1;
  }
  .opacityButton:hover {
    opacity:0.5;
  }
</style>

In this example, the opacity of any element with the class ‘opacityButton’ will be 1 and when you hover over it, the opacity will become 0.5. Basically, the button goes see through when you hover over it.

Did you see how we define hover effects too? It’s easy really, you just add ‘:hover’ after the class and define separate rules for what should happen to the button when it is hovered over.

Here’s how to add hover to our working example button:

<style>
.myButton {
  border: 5px solid #20750D;
  border-radius: 12px;
  background: #21BC27;
  color: #CDFFCA;
  display:inline-block;
  padding:20px;
  opacity:1;
}
.myButton:hover {
  opacity:0.5;
}
</style>

All we’ve done is added the opacity rule to our class ‘myButton’ and then written the same class again but this time with the :hover declaration defined.

Here’s the result:

:hover

But it’s not just opacity that can change on hover, in this example we’ll change the color, border, and background all in one go.

Note, we are not changing the opacity:

<style>
.myButton {
  border: 5px solid #20750D;
  border-radius: 12px;
  background: #21BC27;
  color: #CDFFCA;
  display:inline-block;
  padding:20px;
}
.myButton:hover {
  border: 5px groove blue;
  border-radius:0px;
  color:black;
  background:yellow;
}
</style>

And here’s the result:

:hover

Transition

In partnership with :hover, we can also define a transition value to make the hover effect change faster or slower depending on our tastes. Transitions are measured in seconds and the rule looks like this:

<style>
.transition {
   transition:1.5s;
}
</style>

If you add a transition to both the main class and the class with the :hover modifier, then you’ll get a transition both when the user hovers over the button and when they stop hovering over the button.

The transition value can be different for each. For example, the transition could be faster when the user hovers over the button and slower when the user stops hovering.

Here’s the transition effect in use on our demo button:

<style>
.myButton {
  border: 5px solid #20750D; 
  border-radius: 12px;
  background: #21BC27;
  color: #CDFFCA;
  display:inline-block;
  padding:20px;
  transition:3s;
}
.myButton:hover {
  border: 5px groove blue;
  border-radius:0px;
  color:black;
  background:yellow;
  transition:0.5s
}
</style>

In this example, when the user hovers over the button it will transition to the new styles defined in 0.5 seconds (half a second) but when the user stops hovering, the main styles will take effect over 3 seconds.

Doing more with HTML and CSS Buttons

As you can see there are so many creative ways to style a button. This guide has shown you the basic methods for creating a HTML link element that you can then target with a class (myButton) which we then use to define CSS rules to give the element style.

You can create buttons like this on your website using these techniques but you might have more questions about things like button size, alignment (left, middle, right) and how to add icons to your buttons.

It starts to get a little bit complicated (nothing you can’t handle of course!) but there is an easier way. Here on the HTML Buttons website is an easy to use Button Generator that allows you to change CSS rules using sliders and inputs while the button design updates on the page instantly.

It makes designing buttons super quick and easy and it gives you the code you need to use the button on your website right away.

You can also browse our library of ready-made HTML and CSS Buttons that you can use for free in your web project. You can still customise these buttons to align them left, center, right or 100% width. You can also add icons, adjust the size and even change the HTML tag you want to use.

We also have other helpful guides on creating and using HTML and CSS buttons for your web design projects.

What strategies do you use to achieve deep focus in your work?

Richard Shepherd — Wed, 12 Aug 2020 11:25:24 +0000

Sinking deep into a flow-state of intense focus has always been hard to do but now more than ever.

So what are your favourite ways of achieving deep focus?

If you’re like me, the slightest interruption can have a really negative effect on my work.

This is especially true if I am working out a tricky programming problem. If the phone rings my focus goes immediately and it can take a long time to get it back.

Not ones to sit by, my pal Peter and I decided to try to tackle the problem one step at a time.

We identified that in our own lives the constant attraction of inbound messages (email and IM) was the biggest source of distraction for us. Even without a notification to say there is actually a new message in the inbox, we find ourselves checking ‘just in case’.

I have learned that this is like playing a slot machine: Utterly addictive.

As we all know, gambling should be enjoyed responsibly. It turns out I have a major dopamine drug addiction that’s gonna take some serious rehab to fix. Think Elton 1990.

I need help because constantly checking your email increases stress.

So far I have tried setting all notifications to off on my phone and time boxing email correspondence to the first and last hours of my working day.

However, these methods can only go so far. What I found is that the quality of the conversation makes a big difference too. Conversations in instant message and email are often slow, off-topic and hard to follow. This is particularly true if they are conversations between three or more people.

My hypothesis is as follows: If new features could make conversations online better quality, that will reduce the total amount of messages sent and time spent sending them.

This approach favours the popular sayings: ‘less is more’ and ‘quality over quantity’ .

With this in mind, Peter and I are working on a replacement for email and instant messaging called Plum Mail.

Plum Mail’s objective is to improve the quality of your conversations online with features that are not currently possible in email or available in instant messaging.

In addition, Plum Mail has settings that ruthlessly defend your focus. We’re talking inbox delays, group chat messaging limits, zero notifications by default, a complete lack of user status (active, away etc) and read receipts.

We think Plum Mail has the potential to help you protect your focus. But, we’d love to know more about how you think about your focus and ability to do deep work.

Can you share your favourite ways of achieving deep focus?

The Most Pressing Authentication Processing Pain Points in 2020

Richard Shepherd — Thu, 11 Jun 2020 16:55:52 +0000

I spoke to developers all over the world to find out what are the most pressing authentication pain points in 2020? The results are in.

Authentication online has become amazingly complex in the last 20 years. What began as a simple password problem in the seventies, is now an opulent buffet of different authentication options together with very real regulatory and security considerations. There is certainly no shortage of ways to sign up or sign in to something!

But what are the most pressing pain points for developers and end-users? What does great authentication look like? What does terrible authentication look like?

To answer these questions, I interviewed ten active members of our development community asking what they think 2020’s most pressing authentication pain points are. Each person I spoke to has a different background in the web industry but each has an active interest in authentication. The result is a collection of opinions and authentication pain points seen from different perspectives. So, let’s dive in.

First of all, the strength of feeling surprised me. I know my question asks you to consider what the pain points are so obviously you’re looking for them but what I hadn’t expected was the amount of pain being felt out there. I expected answers such as: “Well, you know, OAuth is a bit tricky’ but what I actually got was multiple pain points from each developer covering a wide variety of concepts. It strikes me that there may be more broken with authentication than I first anticipated:

“It's expensive and dangerous for me to build my own authentication.”
Martin Omander, Developer Advocate at Google.

It’s really difficult for me to be totally sure that my authentication is secure without any vulnerabilities. I always try to follow best practices to be sure that everything is secure but I can’t avoid that little voice in my head saying “you made a mistake”, “your authentication is not fully secure”.
Ale Sánchez, Software Engineer at Rebellion Pay.

The problem I see most often is that software developers don’t put authentication in every single place it needs to be. For instance, you have an application that calls an API and there’s no auth (this happens sometimes). Now imagine that API calls another API and there’s no auth there, this happens A LOT. We assume trust between APIs, containers and other services that don’t reach outside our network, which is a big mistake. Every service and application must be its own island, and implement zero trust, by ensuring there is authentication, then authorization, before granting access to anything.
Tanya ‘SheHacksPurple’ Janca, Security professional and blogger at SheHacksPurple.dev

This is deeper than I thought we’d go on day one and are just three quotes from my research. Developers go to work to solve problems but we don’t get danger money nor do we get access to counselling if we spend a year worried sick about hackers.

So with that, we arrive at pain point one: Security is an ever-evolving challenge, it’s hard to make authentication secure and to foresee all the ways it might be vulnerable. This makes it expensive to develop, expensive to maintain and high risk for someone to take responsibility when the impact of a bug can be so large.

Using someone else’s authentication instead

Of course, you can avoid rolling your own authentication by using a service.

OAuth 2.0 is the open authorization standard used for this. Although OAuth is actually a framework for authorization, it is synonymous with authentication. This is largely because social logins used on websites are implemented using OAuth (and usually OpenID Connect too). ‘Signing in with Facebook / Google / Twitter / Github’ is the norm for millions of users. Some sites, for example dev.to, don’t offer anything else except sign in with Twitter or Github. We have become reliant on these social networks managing our identity for us and while this is a big win (let someone else figure out the hard stuff!), there are downsides too:

Being able to use an OAuth provider, along with the proliferation of good password management software, is a huge win for developers and users alike. I believe that authentication will become exponentially easier as services that simplify the authentication process become available. One downside of OAuth is that we spend less time developing our own authentication, but spend more time understanding and implementing third party solutions. The biggest pain point of authentication in 2020 is that last piece: OAuth. While extremely convenient, it is a process that could be improved.
Aimeri - Full Stack Developer, NC USA.

So in effect, have we swapped one problem with another? Are we really any further forward? OAuth documentation isn’t for the faint hearted. In addition, to offer multiple sign in solutions we need to consult the documentation for each provider. For example, here are all 1830 words of Github’s ‘Basics of Authentication’ guide.

In some cases you’re caught between a rock and a hard place as Yubraj, a FullStack Developer at Etribes describes, when the client demands SSO but without using a third party:

It is difficult to implement one-time login if you don't use thirty party authentication service, I had to go through maze documentation of one of my client's authentication service, it was horrible to test. I had lots of confusion initially understanding OpenId vs OAuth.

Authentication pain point number 2: Third parties carrying out authentication for us are convoluted to integrate with since each one does things slightly differently within the OAuth 2.0 framework. Time is spent working out how to integrate with Facebook, Twitter, Github etc while the need to provide non-branded sign in for users that don’t have accounts with the third parties still exists otherwise you force users to create Github accounts (for example) before they can create an account on your website.

A surfeit of choice

There are some well-known providers that offer to handle identity provider integrations for you. I spoke to Yann in Montreal, a software engineer at PivoHub. He describes a specific issue with Auth0 where users arriving at your website sign in once with Facebook but later return and sign in with Twitter (or another) and the result is two different accounts even if the user’s email address remains constant:

If you use multiple identity providers and the user uses two different providers with the same email, it will create 2 accounts which is a problem. In order to solve this, you must write some custom code which is pretty annoying. They should have a setting for this.

This led me to think, hang on, is choice a good thing? For end-users, are multiple ways to sign up to or into a website actually good user experience?

Okta proudly display a long list of identity providers that come pre-integrated:

Does this look like good UX to you? I suppose it’s unrealistic to expect a website to want to use all of these at once but even three choices could be problematic. Yann’s anecdote shows users forget which social account they used to sign up and end up signing up twice. This is a pain for the developer and a pain for the user.

Circling back round to the developer’s perspective, Martin (developer advocate at Google) says it’s hard to cater for all the ways a user might want to sign in:

It's hard to provide authentication that all your users will like because they have very different preferences. Some prefer to use their Google or Facebook account across all websites. Others prefer creating a new username+password account for each website they visit, for added security. Many users on phones prefer something that requires less typing, perhaps based on their phone number.

And that brings us to the third authentication pain point: there is too much choice.

Try to cater to all users’ needs and you end up with a list of authentication options as long as your arm. This, in turn, causes choice paralysis and problems in the backend when a user tries to sign in or up multiple times using different identity providers.

Provide too few options and not all users can access your website. We see this in the case of sites that exclusively offer social login and no email based alternatives.

In addition, too many authentication options cause choice paralysis for the user and later, if after a long session, they re-authenticate using a different social network they run into problems.

I got chatting to Diego, a Facebook employee. His views are his own and not those of Facebook. I asked the question: Are social logins a developer's friend? Do they make life simpler? Do they do the opposite? Diego answered:

It depends. Are they making it harder to reason around accounts? Yes. Are they making it harder to store an unencrypted password that will be credential-stuffed into a fake leak that causes mass hysteria? Yes.

Diego’s beef is with the alternative to social login, i.e. username and password setups on every site. So yes, social login is tricky to implement but at least it means you don’t have to store hashed passwords in your database which is a definite plus.

If you do decide to start storing passwords, regulations make storing Personally Identifiable Data risky as explained by Martin Omander, of Google:

Storing PII (Personally Identifiable Data, like name or email address) is risky and increasingly regulated. PII in your database is basically a liability. The easiest way to comply with privacy regulations is not to store any PII at all. How can I do that, but still provide secure authentication?

Martin and Diego’s points go hand in hand. How do we reconcile the gap between these two pillars of authentication, neither of which are ‘perfect’?

Martin again:

I do hear from users every now and then about log-in methods. They say one of two things: 1. I don't want to have to come up with yet another username/password combination. 2. I don't want federated sign-in because I don't want anyone to see which sites I visit. I prefer good old username/password.

These conversations lead me to think that pain point four, is that there is no obvious answer to which authentication method is best. There is always some level of debate required. There is no ‘de-facto’ authentication method that reconciles these problems.

The requirements for authentication seem rather simple in essence:

Authentication should be secure.
It should be very easy for a developer to implement secure authentication.
Authentication should be convenient for the end-user.

Nikola, Director of Engineering at Teltech, summarises it perfectly:

Imho, it still seems that, even though we're in 2020, there's just too much fuss with getting authentication to work. It would be great if you could just call one function and woila 🤗.

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.