Federated authentication is the new best practice for login processes - see why login as a service is now a valid proposal.
Usage of Federated Authentication
Single-Sign-On has become very popular for many cloud applications due to the improved user experience it offers: it is no longer necessary to sign up with a username and password in most web properties, but with a few clicks one can log into a website by using the existing Facebook / Google / Microsoft account. With the introduction of cloud applications to the corporate world, this comfortable login method was rarely offered. For Sitecore applications in particular, the “old” option was to connect Sitecore to the active directory of the user. While this worked most of the time, it required the servers to be part of the domain – which wasn’t always what the client’s IT wanted nor was it practical to implement.
To enable single-sign-on for corporate applications and make sure people do not need to remember many passwords, federated authentication (or claims based authentication) is more and more often seen as the best practice. This does not only increase the login comfort, it also makes sure that it is not necessary to share credentials with providers of SaaS applications (or less-trusted internal applications). Compared to active directory connections, the coupling between the applications is less tight. A login can even be implemented directly in a frontend application (SPA).
On a related note: Digital Identities
While these technologies can be used to simplify and secure logins within a company, they can also be used to create digital identities in a broader sense. Industry conglomerates and governments are both working intensively on digital identities that should be used for everything from online shopping to e-voting. These efforts are also mostly based on the concepts of federated authentication discussed here.
Login as a Service
While everyone can set up their own service to be used in a federated environment (and many already have), there is a multitude of services that offer this functionality in the cloud. While probably best known, Facebook and Google are probably not the best choices for the enterprise environment. For enterprise requirements, Azure Active Directory, Auth0 or Okta Identity Cloud are often the better choices. Both offer the possibility to sync with existing active directories and therefore quickly allow all your employees to use federated login via their service. Of course, they also offer APIs to manage users and groups which might be handy if you already have a more complex IAM (identity and access management) solution in place (and there are no existing integrations).
Technology & Integrations
While the providers of federated authentication services emphasize the simplicity of their solutions, integrations into custom solutions still need a good understanding of the technologies and standards that are in use (mainly OAuth 2.0, OpenID Connect and SAML). In addition to the know-how about these standards it’s also important to have a good understanding of the applications that should be integrated.
Sitecore and Federated Authentication
I wouldn’t be a good Sitecore developer if I would not write a chapter about the use of federation in Sitecore projects. While there have been custom integrations with federated authentication services have been around for many years Sitecore 9.0 offered out-of-the-box integration for the first time. With Sitecore 9.1 federated authentication will be the default authentication method. You will basically need to set up an instance of Identity Server (https://github.com/IdentityServer) which will then handle the login to Sitecore. Of course, this is only a replacement for the internal user database. Most users will integrate with existing authentication servers to leverage the usage of existing user directories. This will hopefully be the end of “admin” / “b” logins (white hat hacker Mikkel Romer found that 5% of Sitecore instances available from the internet have the standard admin login active).