1 Introduction
Let’s spare a thought for software developers who are commissioned to develop programs but often without the necessary support infrastructure. They need to provide access control to their applications but in many organizations there is no common authentication mechanism in place to service the company’s multiple applications. In many cases there are separate authentication methods for on-premise web-apps, client-server applications and SaaS apps. Without a comprehensive authentication solution developers must spend time and effort to develop appropriate interfaces that allow users to enjoy an SSO experience when accessing corporate applications. With this effort spread over multiple developments the risk of error and consequent vulnerability in the organization’s access control infrastructure increases.
In order to manage staff access to applications an authentication solution must be able to leverage the organization’s identity repository; as new staff are added to this identity store they should be able to access applications to which they have entitlement. More importantly, when they leave the company’s employ their access to applications should be automatically removed.
If an application is to be accessed by external business partners the authentication task is more complicated. Often an administrator manually adds authorized business partners to the corporate identity store but this adds a management impost to continually monitor the partner organization in order to remove or add accounts when staff roles in the partner organization change. A better solution is to federate with the other company’s identity provider service but this too represents a management impost if the activity must be replicated for multiple partner organizations.
If an application is to be accessed by members of the public the authentication task is further exacerbated. A typical solution is to use a public identity provider services (IdPs) such as GoogleID or Microsoft Live. This is an attractive option because it means users login via their social login credentials rather than being issued another username and password to remember, or write down! In cases in which social logins are considered inadequate from a registration assurance perspective (anything above NIST level 1) a commercial identity provide service is required. Most developed countries are deploying such services in conjunction with government initiatives.
In these instances, a common authentication infrastructure providing a single interface for users but supporting multiple standards for integration with IdPs is very attractive; otherwise developers must integrate to multiple IdPs on a per-application basis.
Yet another issue for developers arises when an application owner requires a higher level assurance for staff access to an application. For instance, the financial management system might be deemed sensitive requiring a two-factor login. In this instance a mechanism must be selected and developed that will satisfy the company’s requirements. This might be a simple SMS to a smartphone, a smartphone gesture login, a FIDO login on a mobile device or a biometric login, but it represents a significant cost if it must be developed for multiple applications.
Another important feature of an authentication service is the ability to easily add new applications when they are acquired or developed. There should be little impact on users when a new application is added and entitled users should be able to log into the new application with the same credentials under corporate the SSO environment.
To assist developers and remove the task of managing multiple authentication options there are a number of on-line services that provide a consistent programming interface for user authentication. An industry leader in this sector is Auth0, an on-line authentication service with extensive programmer support.
Auth0 provides a common interface for developers to use in order to abstract the login process to an external authentication service. This means that the authentication service can be managed separately to suit the specific needs of relying applications, removing the need for the programmer to understand the authentication practices that various organizations adopt and reducing the coding costs by removing logic and potentially multiple connectors from the development task.
Auth0 is a privately held company headquartered in Washington State in the USA.
