Introduction

Consumer Identity Services, are focused upon delivering functions such as the following for users accessing services across the internet:

  • user registration
  • password reset
  • profile personalisation
  • passwordless login
  • multi factor authentication
  • session management
  • adaptive and contextual access
  • privacy & consent management

Example services could include on line banking, online retail and sign up access to government services.


Concepts

API First – consumer based identity services will need to be delivered across a range of different application types and platforms. Consumption devices will include mobile, tablets and responsive single page applications, where access to REST and JSON based API’s for the configuration and consumption of identity services will be critical. The management of services is also important, so having underlying management API’s would allow for the development of customized, focused and specific delegated administration capabilities.

SDK Enabled – whilst being API first is paramount, the secondary level of acceleration is for the embedding of software development kits into the consuming applications. SDK’s should be available for the most popular mobile operating systems – latest releases (and previous 2) for both Android and iOS. JavaScript is becoming the de-facto standard for both front end and back end application development, specifically when it comes to single page applications. A JavaScript SDK would be a powerful addition.

Scaleable – consumer facing systems will encounter scale in numerous different areas. Clearly, the total number of users accessing the system could be in the magnitude of 20 times higher than that of an employee based identity system. So the ability to store hundreds of thousands and perhaps millions of user records is important. The next item regarding scaleability is service throughput – how many transactions per second is achievable for the identity and access services being offered? Not only does the user population have an impact, but also usage patterns. For example, can the system be expected to handle peaks and bursts of usage? Are they known?

Elastic – usage and scale within an Internet facing system, is likely to be non-uniform. Employee focused identity systems, can be nicely tied to usage patterns – namely employees start work between say 8 am and 9 am. During this time, a burst of authentication activity can be expected. Within Internet consumer facing systems, users could be highly distributed, where usage patterns can either collide or diverge, requiring the ability to rapidly scale – or be scaled back – when it comes to growing and shrinking cluster capacity. It is important to take the level of elasticity into account and not just peak load.

Distributed – Internet facing systems, could be accessed from anywhere in the world. Whilst many commercial systems will be targeting specific user territories, or perhaps verticals, it seems inevitable, that the underlying identity service, would need to be globally distributed, across different data centres and locations. Can intra-continent communications be configured to allow the basic feature set to work seamlessly across different regions? How does this integrate with disaster recovery and business continuity planning controls?

Modular – consumer trends change rapidly. Patterns of commerce change rapidly. A consumer facing identity system, whilst there to provide a relatively static, albeit constantly evolving set of services, must be modular enough, to allow for the rapid extension of services to cover unknown-unknown style demand for new features. Being modular (perhaps micro-services based, albeit not essential) allows for the future-proofing of functional design, to allow for changes in demand for say, new authentication methods, changes to standards and so on.


Standards

OAuth2 / OpenID Connect – the de-facto approach for JSON based authorization and identity assertions. See the OAuth2 Capabilities Matrix for an example of some of the specific protocols within OAuth2 that would be essential for a consumer facing project, including MTLS and PKCE.

WebAuthn – passwords are dead, long live the password. Unfortunately passwords are still everywhere and the main first step for identity authentication on many systems. WebAuthn, is a standards based approach to tackling the password-less problem. It can improve security, whilst also improving the user experience, something that consumer facing systems demand. See the WebAuthn Adoption Analysis article for more details.

JWT – JSON Web Tokens are a means of serialising information in a secure way, that can provide non-repudiation and also and confidentiality if also encrypted. Many OAuth2 access tokens use this format and OpenID Connect id_tokens do use this format. There are multiple libraries available for a range of languages and can be easily implemented securely.

Categories:

Tags:

Comments are closed