I’ve been a programmer and IT enthusiast for 30 years (since the zx spectrum) and concentrated on AI (neural nets & genetic algorithms) at University. My principle skills are concentrated on Enterprise and Solution Architecture and managing effective developer teams.
I enjoy the mix between technical and business aspects; how technology enables and how that (hopefully) improves profit/EBITDA & reduces cost-per-transaction, the impact upon staff and how to remediate go-live and handover, and risk identification and mitigation. My guiding principle is “Occams Razor” that simplicity is almost always the best option by reducing complexity, time to build, organisational stress and longer term costs.
Centralising User Management - Why Single Sign-On (SSO) can improve your customer's lives
Single Sign-On ("SSO") isn't glamorous but it's often the keystone to making life easy for your customers.
When customers use your services / sites / platforms they want everything simple and easy to use. We've all had the frustrations of registering for multiple accounts, trying to remember which password to use, and being forced to login again and again.
Single Sign-On seeks to get around this problem by managing registrations and login in a central place. Users then get a uniform approach regardless of which site/platform they're trying to use and you centralise your user management which is better for security, GDPR concerns and for your reporting.
Building an SSO can be created in different ways depending on your needs. In some instances there are off-the-shelf systems that can be utilised (JanRain for example) but these can be expensive and proprietary.
Our preferred approach is to customise SSOs to the individual needs of the client. In this way we can ensure that the registration and login flows (as well as forgotten password and account management) are tailored to ensure that the client's customers get the best user experience they can. In our experience bad user journeys begin with registration woes and that leads to bad engagement and potential lost revenue.
There's a number of ways to build an SSO but really you need to decide a few things:
- Do you want to use email & password as a login scheme?
- Should customer's login using "federated identity" / third-party logins - for example LinkedIn, Facebook, Google, Microsoft etc
There's advantages to both approaches but using email and password means you manage the security aspects of handling passwords. Over the years this has been the de-facto way of managing logins so people are used to it. However for some areas (and the younger generation) it makes sense to use third-party login.
Third-party login enables you to know more about your customers and allows you to message them more easily. For example let's assume we use Facebook as a login, we can then recommend that they join a page around your products and engage better with you. We can also more easily allow those customers to share information (using Facebook) direct from your platform.
But, there's no need to pick one over the other. With a well architected SSO you can allow customers to pick their preference of login method.
We're great fans of internet standards like OpenID Connect / oAuth2. These protocols are very secure, well understood by engineers around the world and have excellent support in both programming languages and development tools.
Integrating an SSO is usually extremely simple and customers logging in or registering follow a flow like this:
- User goes to the Customer's website
- User attempts to access something that needs them to login or register (or they choose to login) - for example buying an item from a shop
- User is sent to the SSO
- User logs in or registers
- User is sent back to the Customer's website
- Invisibly the Customer's information is securely shared with the website
If you're like to see this in action then try logging into gmail or xbox.com - you'll see that you're sent to google account or microsoft account respectively and that's how those 2 major players use SSO to ensure that you can use all of their services.
I think it's best that we give a worked example. Let's use our preexisting Access ThankQ SSO solution for a fictional charity providing training and support to its members.
Our example charity has:
- A training website that members use to validate their skillsets
- Member website where members can login and manage their benefits
- A gifting website where members can donate to the charity
And is thinking of expanding in future..
In a traditional approach both websites would have a login and a way to manage member details.
With SSO we can create a simple way to centralise login and member details. Regardless of which site the customer accesses they'll use the same login mechanism. Plus once they're logged in then it'll get remembered.
Let's assume that the example charity has a facebook page and most members use this page. We could get the SSO to allow a user to use either their facebook login or their email and a password.
Assuming facebook is used we have a very simple registration journey as most of the details we require can be pre-shared by facebook (with the user's consent of course!). A user would click "login with facebook"; if we've seen this person before then it will log them in if they are logged into facebook (if not then they log into facebook and it completes), if not then we create their user.
As we now know their facebook user we can validate if they're a member of our facebook group. We can also add easy "share this on facebook" widgets to the websites.
Assuming we used our Access ThankQ Single Sign-On solution then all websites can then use the ThankQ APIs securely too and we can manage users directly within ThankQ without writing any additional code.
Having your own SSO also can have an added benefit if you want your users to log in to other sites.
Why would you want this?
- You have an affiliated organisation - for example with our charity it could be another charity that's complimentary - if our charity was around lawn tennis then we may want our members to log in to the other tennis sites
- Other sites need to identify your members - a good example is for giving offers to your members. The user gets a discount by being a member can be easily validated by asking them to login
All logins can be managed so you'll know how many people are going to each site too.
In these situations you choose how much your SSO can share and your user's are aware of this and can reduce the sharing. In some cases you may want the user's address to be shared (with their consent) in others you may just need their membership number. By doing this you're in control of the information flow and you know that it's secure for your users.
SSO is a powerful tool. Used correctly it can make your customer's lives significantly better while improving your security (and reducing your development costs) significantly. If you've got multiple sites/applications then it's worth considering for your future roadmap.
Working In Partnership
We're up for (almost) anything.
Our partner network is continuing to grow with like-minded companies that can add value to our mutual client offering. If you would like to learn more about how we can grow together get in touch.