Let us start with a few definitions just to get started. Authentication is focused upon asserting the properties of an entity and confirming a level of assurance. The typical process of signing in or logging in. Clearly authentication for people is quite a well known process, as we perform the task every day – sometimes several times a day. Authentication can also occur for services, devices, terminals and other non-interactive events too, often using challenge response processes, certificates and cryptography. Authorization on the other hand, is very much focused on access control – what can the identity asserted via the authentication process do, when can they do, where and at what time. There are several ways of modeling and enforcing authorization controls and that is a piece of research The Cyber Hut will be releasing in Q4 2021.
When it comes to authentication however, we have witnessed quite an interesting journey. Not only has authentication changed in scope and priority, it has also evolved from its location within the identity life-cycle. What does this mean?
Application Silos
It is quite common to still see authentication being tied into an application or service directly. The service will have its own authentication service, with policies, an identity store and methods of authentication. It is not tied to any other system and a successful login event to this one system has no leakage – the session information cannot be used elsewhere. This is a bit like buying a ticket to a cinema and expecting it to work at a baseball game. It is quite limiting from an operational and security standpoint however.
So what is the alternative? Well, some applications may well need to be kept separate due to logical or functional requirements. However many applications, especially in the enterprise space, can often be grouped together into “security zones”, where authentication requirements are so similar they can be grouped. This grouping is the basic single sign on (SSO) design pattern. Logging in once to a centralised identity provider, with multiple applications integrated to use the same login-session-logout events.
Integration With An IDP
The IDP pattern clearly needs to perform two main functions: provide a range of authentication options and secondly be able to provide the authentication event information into a range of different application types.
So IDPs typically have a long history of being capable and extensible. Authentication options out of the box need to provide a super-set of all the authentication options from the previously separate applications. So integration with persistent identity repositories such as Active Directory, standard LDAP and databases is table stakes. The increasing need for multi factor authentication would see the likes of OTP (one time passwords) delivered by the now obsolete methods of SMS and email as well as more secure approaches using local OTP generators based on the OATH standard embedded within mobile applications. Push authentication would be popular, alongside cryptographic challenge response style approaches based on FIDO and WebAuthn. Native biometry (either using local authentication via the mobile device in the form of fingerprint or face or via a proprietary method) would also be likely. So how does the authentication event against the IDP get used for the downstream systems?
The IDP needs a method of integration – that is bidirectional and extendable. It’s likely the IDP would have one or more of the following:
- An API for performing an authentication event
- The ability to issue cookies or tokens on completion of a successful event
- A remote gateway (or app specific agent) for validating tokens
- An API for validating tokens
- A notification system for logout events – likely using something event hooks or web sockets notifications
- An SDK for accelerating application call backs to the central service
So What Comes Next?
The IDP and SSO model of authentication is popular, mature and well documented. There are numerous vendors in this space that provide dedicated single sign on services. The modern enterprise however doesn’t just have one IDP. It is likely they will have numerous. Some on-premise, some cloud based, some leveraged by partners or supply chain providers. So the authentication events move from being silo’d at the application level, to being silo’d at a business boundary or federation level.
As the operational landscape has become more fragmented and interdependent, the demands on authentication services has evolved too. Authentication is not static – it is being driven from both an evolving threats perspective and also a usability angle.
A quick Crunchbase query reveals 159 funding rounds related to authentication technology since January 2018 – resulting in a staggering $3 billion of investment. The authentication problem still clearly isn’t stable or “solved” with such innovation taking place. What does that mean for the IDP? Well they need to evolve too and be able to respond to changing demand for authentication functionality. IDPs however typically don’t get swapped out regularly. They are complex middle-ware beasts with long lifespans up-to 7+ years. The authentication aspect however is almost constantly evolving.
It seems the most logical step is to decouple again – this time away from the IDP and protected application mechanics.
So what might that decoupling look like?
There are probably two drivers again – an ability to evolve the authentication mechanics (emerging biometrics, passwordless) as well as consistent usability across the entire spectrum of application types – on-premises, cloud, consumer, employee, legacy and so on.
It is an interesting topic of emerging design. I will be discussing this area further on August 19th as part of a fireside chat with Hypr interim CEO and CTO Bojan Simic. Sign up for free here.
See the following related articles on authentication design and evolution:
- Let’s Treat Authentication as a Life-cycle
- The Role of Mobile During Authentication
- You’re Only As Strong As Your Password Reset
- What Does Web 3.0 Mean For Identity?
Simon Moffatt is Founder & Analyst at The Cyber Hut. He is a published author with over 20 years experience within the cyber and identity and access management sectors. His most recent book, “Consumer Identity & Access Management: Design Fundamentals”, is available on Amazon. He is a CISSP, CCSP, CEH and CISA. He is also a part-time postgraduate on the GCHQ certified MSc. Information Security at Royal Holloway University, UK. His 2021 research diary focuses upon “How To Kill The Password”, “Next Generation Authorization Technology” and “How IAM Countermeasures Can Defend Against Cyberwar”. For further information see here.