Authentication (B2C)

To provide services to your users, you must be able to identify who those users are. This process is called User Authentication. There are a number of ways to perform authentication of a user—via social media accounts, username and password, passwordless—and it's often recommended that you go beyond a first factor for authenticating the user by enabling multi-factor authentication (MFA).

Best Practice

It's important to consider both security and user experience when designing how you will authenticate your users. Providing for multiple primary factors, and/or enforcing more than one factor during authentication, are ways that you can provide both.

There are a number of things you will want to consider when looking at functionality and workflow:

• Where will users enter their credentials?

• How will you keep user credentials safe?

• How will you maintain your authentication system?

• How can you provide password authentication for your users?

• How can you prevent hackers from trying to log in as your users?

• How will you implement authentication in different kinds of applications?

• How can you make login easy for your users when they come from different language backgrounds?

• How will you provide a good user experience as you migrate away from any legacy authentication system?

• What should you consider when integrating applications with Login 3.0?

• Can users log in using their existing social (e.g., Facebook or Google) accounts?

• Do you need to provide multi-factor authentication?

• What do you do if you have a service that doesn't have a way for the user to log in ahead of time?

• Can you pass the same user access token from one API to another?

Login 3.0 provides users with a safe and secure experience—no matter whether you choose to provide for user ID/password credentials sign in, or allow the so-called Bring Your Own Identity scenarios provided via Social Login. There are also brand recognition benefits to centralizing the login experience with Universal Login, even if you feel you will also have product-specific branding requirements. The Login 3.0 UI widgets typically used with Universal Login also provide out-of-the-box support with regards to internationalization for users with different language requirements. Configurations related to these features must be requested and handled by the UPBOND team.

Allowing users to sign in via user ID/password credentials means that you're not reliant on the status of third-party identity providers for your users to access your system. You also have the means to require the credentials used to align with your corporate policies. Login 3.0 assists with this by providing you with multiple options in support of user ID/password logins, and the guidance provided will help you understand how you can leverage these options. Adding social support at some stage, as an additional primary authentication factor, gives you added flexibility and can help you better understand your users without the need to question them further by leveraging the information already stored by the various social login providers.

If you have an existing legacy identity store, you’ll also want to see User Migration. This section discusses the advantages of migrating to Login 3.0’s managed identity storage in terms of safety and security. Migration configurations must be handled by the UPBOND team upon request.

For customer-facing applications, OpenID Connect (OIDC) is the most frequently used industry standard protocol, and OIDC has first-class citizen support in Login 3.0. Login 3.0 provides support for various different approaches for integrating various different applications, so you'll want to see the section on application integration for the information you'll need to make an informed choice.

When calling one API from another API, or from any situation where there is no authenticated user context—such as one or more cron jobs, report generators, or continuous integration/delivery systems—you will need a way to authorize the application instead of a user. This is a one-step process where the application is authenticated (using a client ID and secret) and then authorized in one call. You can learn more about this in our authorization workstream under machine-to-machine (m2m) authorization.

Universal Login

Do you have, or will you have, more than one application in your system? If the answer to this question is yes, then you will want a centralized sign-in experience. To achieve a seamless Single Sign-on (SSO) experience between multiple applications, it is critical to have a centralized location to redirect your users for authentication. This allows you a way to provide your users with a consistent experience if you add social authentication in the future, add third-party applications to your system, or add multi-factor authentication as an option (or requirement) for your users—and also allow you to take advantage of new features for improving your users’ experience with little, if any, added development effort. Configuration of Universal Login features must be requested from the UPBOND team.

Best Practice

If you have more than one application, the best practice is to redirect to a centralized location to authenticate the user. With Login 3.0, this means taking advantage of Universal Login, which provides many security and user experience benefits out-of-the-box, including SSO.

Login 3.0 Universal Login makes authenticating users a short, easy process that can be accomplished in three easy steps:

1. Determine how and when you want to redirect from your application.

2. Request setup of the appropriate branding and/or customized HTML in your Login 3.0 configuration by contacting the UPBOND team.

3. Set up your application to receive and handle the response from the Authorization Server.

Application Integration

Once you've figured out how you want to authenticate your users, the next step is to determine how you will initiate that authentication. Each application will typically have its own starting point.

Native mobile applications (and desktop applications) should use the system browser for authentication, or they open themselves up to additional security risks. See Native vs. Browser Login on Mobile for more information.

As discussed, we've found that most of our customers use OpenID Connect (OIDC) as the industry-standard protocol when it comes to their customer-facing applications. Figuring out which OIDC flow to use is your first task, and you will want to start by reviewing our grant mapping guidance in the first instance.

If you want to allow anonymous users access to any part of your application then you need to determine if you will be redirecting right away or prompting your users to redirect only when required (or perhaps some combination of both; see Redirect Users After Login for further discussion). If users can deep link to a protected version (or area) of your site then you will need to determine the links to your application that will result in an automatic redirect to Login 3.0.

Anonymous Access

It is important to consider the user experience when someone first comes to your application. If your application supports anonymous user access (quite common for eCommerce applications) there are different scenarios to consider:

• Are they returning to the application after having already logged in, or

• If this is the first time they are accessing the application:

  • Have they already accessed a different application that uses the same Login 3.0 tenant,

  • Have they ever (or perhaps not in a long time) authenticated on this device or browser.

When an anonymous user accesses your application, it can often be desirable for the application to discover if the user has already logged into a different application in the same family, or to remember this user even if the application is a SPA with no state. For example, if you can determine that the user is already logged in, you might decide to have the UI header in the application skip displaying a login button and instead have an account or profile menu for the user. To accomplish this you will want to utilize "silent authentication." Silent authentication will allow you to check to see if the user is logged in without prompting them to log in if they are not. Then the application can present a login button if necessary. If the user is logged in already, however, then you will receive tokens and will not have to present the user with a login button