It used to be common for software companies to build standalone websites. This ensured that login screens looked the same as other areas of the app. An example theme for a bank website is shown below.
These days, most companies instead use an Identity and Access Management (IAM) system to manage authentication for their apps. OAuth 2.0 and OpenID Connect are the main standards used, which have first-class support in any web, mobile, or API technology stack.
Using an IAM system, you externalize the difficult security from your apps, enable many more ways to authenticate, and allow these methods to be chained into a Multi-Factor Authentication (MFA) workflow when needed. You then have a security toolbox that enables both secure and user-friendly sign-in, including options such as Google, One Time Passwords, and WebAuthn.
Meanwhile, the requirement for branded login screens, that look and feel like the rest of your app, remains as important as ever. This will be a critical requirement in some industries, such as medical or government. When using OAuth, you need to ensure that you still have control over the look and feel. Therefore, in this post, I will describe some important login behavior to look for when integrating OAuth into your applications.
First, you will choose the authentication options to use, depending on the type of data involved. When login is only for personal assets, options such as social providers can work well. However, when corporate data is being accessed, the business will want to only allow corporate users to sign in. Medical or government systems may also require custom factors to prove the user's identity. The IAM system provides building blocks to enable your preferred behavior.
The second part of designing logins is the look and feel. The IAM system should provide productive tooling to enable you to quickly customize screens, to add logos, your preferred colors, and other CSS attributes. The Curity Identity Server enables this via its Admin UI, as illustrated below.
Localization can be important for some companies when targeting global users. OpenID Connect has a ui_locales parameter that can be set to the user's current language when triggering a login redirect. If you need this behavior, ensure that your IAM provider supports the localization of login screens and customization of the text displayed.
These days mobile usage exceeds desktop usage, and users will run both your web and mobile apps from devices. If this is the case for your apps, you should make the mobile user experience your first priority. Test that layouts work well for expected device sizes, but you may also need to think about login difficulty since this can be more challenging on small keyboards.
When users enter passwords, a common option is to use the password autofill features of the device so that users do not need to continually type it. Similarly, storing a refresh token in secure mobile storage can prevent the need to log in on every app restart. This type of usability feature is often combined with additional factors to help protect against stolen devices. Opt-In MFA can be useful for enabling users to choose their own preferred factors.
Mobile authentication can use the AppAuth pattern, which manages login redirects using an integrated form of the system browser. A more cutting-edge option, with higher security and also best control over the look and feel, is to manage logins via the Hypermedia Authentication API (HAAPI). This prevents the need for login redirects in many cases, enabling you to avoid using external login screens altogether.
The primary behavior to look for in an IAM system when implementing custom branding is extensibility. At many companies, different branding per client app may be required, so check that your IAM provider supports this. For example, in the SecureBank scenario, the custom theme might be designed for internet users. It should then be possible to use a different login theme for a specialist app targeted at investors or for internal products.
Another example is a medical system that uses a custom authentication factor, requiring an additional screen as part of an MFA workflow. The data entered may then need to be verified by a medical API. It should be possible to build these types of solutions using the IAM system's SDK, and the custom look and feel should then also apply to the custom screen.
Also, review the CSS support from your IAM system, which is critical to getting the look and feel just right. Some providers may only provide basic options, but companies who deliver state-of-the-art UIs may also want to use custom CSS frameworks or special fonts. Finally, ensure that any customized HTML assets are easy to deploy, including when the IAM system is upgraded.
Creating a Modern Login UX With the Curity Identity Server
Above, I summarized the critical behaviors needed to provide a modern user experience. Firstly, the IAM provider should enable fine control over authentication workflows. Secondly, it must be easy to customize the look and feel and take finer control over the different branding per client.
The Curity Identity Server is built with a separation of concerns philosophy so that all the essential areas are extensible. To get started, you can customize the look and feel using the Admin UI, then take finer control if needed using the UI Builder tool. For further information on the topics from this blog post, see the below links: