Workforce IAM – The Evolution which is a Revolution: The Impact of CIAM on WIAM
- More and more software solutions support the new authentication and authorization protocols.
- Companies are using software from the cloud, which means that old IAM solutions are overtaxed.
- Authentication with only username (or email) and password is no longer secure enough, multi-factor authentication methods cannot be added or only in a very limited way.
- Today’s employees work in distributed and mobile environments, internal solutions need to be externally accessible.
In our new two-part blog series “Workforce IAM – the evolution which is a revolution”, we take a look at the changed framework conditions for Workforce IAM in the meantime and show that more than 95% of all IAM innovations come from the area of customer identity & access management and general digitization.
What are the new de facto standards of a Workforce IAM?
In the past, authentication and authorization in enterprises were inevitably linked to directory services. It was convenient to create “objects” in the directory that represented either a person, an organizational unit or an application. These objects were partially standardized. However, management in LDAP (Lightweight Directory Access Protocol) was inconvenient, and all applications required privileged access rights to authenticate users or devices. Particularly problematic was that the applications also had to perform user authentication independently, which led to varying results depending on the quality because sensitive user data was involved.
In the area of Identity & Access Management (IAM), Customer Identity & Access Management (CIAM) has fundamentally changed the landscape. This is due to increased security requirements, user convenience, and the need to securely access enterprise Web APIs. In this context, Web APIs have become key factors in the IAM environment thanks to standards such as OAuth2, OIDC (OpenID Connect), and to some extent still SAML2. They act as a hub for authentication and authorization, providing a secure, standardized, and user-friendly environment.
Traditional IAM concepts are based on applications performing user authentication themselves, i.e., implementing their own user login. However, this results in both security and application problems.
Some examples of security issues:
- Applications gain knowledge of user credentials.
- Applications must always have access to the IAM and receive technical user credentials for access.
- The communication protocols between the application and the IAM are not suitable for use on the Internet.
- Each application often has its own security level implemented; uniform, maximum security across all applications or channels is not possible in a simple way.
- If new authentication methods are to be provided, the applications must be adapted. New IAM functionalities are thus not available time-to-market in all digitization solutions.
Some examples of application problems:
- Changing structures in the IAM is complicated.
- Using additional MFA authentication methods is very difficult because the applications usually have to be adapted.
- Single sign-on is often problematic because session management cannot be solved in a standardized way. Thus, the user often has no choice but to log on again to other systems with the same user information.
Today’s standards such as OAuth2 and OIDC effectively decouple authorization and authentication from applications. When a user uses an application (which is a protected resource), that application requests authorization for the user from Identity & Access Management (IAM). The IAM checks if the user needs authentication and displays a central login dialog. After successful authentication, the application receives an “Access Token” and, if applicable, an “ID Token”. These tokens provide secure access to additional resources, such as web APIs, and contain information about the user. In order for this system to work, the application must first be registered with the IAM. This allows the IAM to process the application’s requests and ensure that only authorized and authenticated users can access the protected resources.
OAuth2 and OIDC also standardize the procedure for defining authorizations so that systems (clients) can access other systems (resources). This is done by using “scopes” to identify resources in order to ensure that the requesting systems have the appropriate permissions. Furthermore, by largely standardizing the content of the tokens, it is possible to easily manage and check authorizations for very different software solutions using a modern IAM.
This also explains the rapid success of these standards for applications that are operated within the company, as well as cloud solutions.
Conclusion
In short, Identity & Access Management (IAM) in enterprises has historically focused on internal organization, employee access, and documentation of access rights, but this traditional focus has fundamentally changed in the meantime. With the advent of Customer Identity & Access Management (CIAM) and advancing digitalization, as well as changes in the software landscape, particularly the use of cloud solutions and distributed, mobile work, the requirements for Workforce IAM have changed significantly.
Traditional IAM concepts based on applications performing user authentication themselves face significant security and application problems. Thanks to OAuth2 and OIDC, resources such as applications can be easily connected to the IAM. Moreover, OAuth2 and OIDC have brought about a decisive change in the IAM landscape by decoupling authorization and authentication from applications.
Read also our second part of the blog series: Workforce IAM – the evolution which is a revolution: The (R)evolution of Workforce IAM
You may be also interested in our blog: The shift from on-premise to cloud-based IAM solutions: Trends in Identity & Access Management (IAM)