kevin strong-holte

All content in this article is for demonstrative purposes only. Any resemblance to existing companies, products, or features is coincidental and does not imply ownership or association.

Feature A vs. Feature B

When you design the login experience for your application, you’ll need to decide if you want to use Feature A or Feature B.

Feature A

In a Feature A flow, the application redirects the user to the Platform Authorization Server to perform authentication, and then the Platform Authorization Server returns the user to the application.

In the typical user authentication experience with Feature A:

  1. Your application triggers an authentication request by invoking Platform SDK’s login method or by calling the Platform API login endpoint directly.

  2. Your application redirects the user to the authorization server.

  3. Platform checks for a session cookie on the intermediate session layer.

    • If a session cookie is not found, Platform redirects the user to Feature A to authenticate and creates an associated session cookie.
    • If a session cookie is found, Platform uses it to authenticate the user.
  4. Platform returns the user to your application with an ID token and an access token.

Feature B

In an Feature B flow, the user authenticates directly within your application. The application serves the login form, collects the user’s credentials, sends that data to the authentication provider, and then receives a response with the user’s ID token and access token.

For web applications, Feature B uses cross-origin authentication unless you configure a custom domain for your tenant. Cross-origin authentication uses third-party cookies to allow for secure authentication transactions across different origins.

Feature comparison

Product areaFeature AFeature B
Single sign-onFull support with Feature A through the use of session cookies on the authorization server.Limited support. Web applications that use the JavaScript or Go libraries can share sessions. Native applications can share sessions with web applications through Feature C.
CustomizationFeature A allows you to easily customize many parts of the experience (including theming, page templates, text elements, and prompts). Full customization is supported through Smart Customizations for Feature A.Highest degree of customization, since you fully control the UI/UX of your application.
Feature managementFeatures can be centrally managed within the Platform Dashboard or through the Platform Management API. For example, when you enable/disable MFA in the Platform Dashboard, it will be immediately reflected in subsequent user logins.Features must be managed for each application individually. For example, if you wanted to implement MFA for your web application and for your native application, you’d have to update and release new versions for both.
User experienceUsers are redirected between your application and the Platform Authorization Server during authentication. For native applications, this requires implementation of universal/deep links.Users remain in your application during authentication.
Security and maintenancePlatform monitors security trends and updates Feature A accordingly.You are responsible for following security best practices and implementing provided technologies accordingly.

Best practice

According to RFC 8252: OAuth 2.0 for Native Apps | IETF, only external user-agents (such as the browser) should be used by native applications for authentication flows.