[cross-case] Intermediary usage

[timcappalli]

Protocols like OpenID Connect are used by some products as an integration strategy between IDaaS (Identity as a Service) products and end-user-facing apps. These hosted services are often deployed outside of the same-site scope of the end-user-app, and exist in both enterprise and consumer varieties:

• www.customer.example: user-facing app
• customer.idaas.example: idaas service, possibly with per-tenant origin

The idaas product may do local user management and session management, such as attempting to keep a common authentication session going to do do a transparent single sign-on across multiple applications by the customer.

In addition, the IDaaS may provide a broad range of authentication options - traditional username/password, SMS or app-based MFA challenges, Web Authentication. They may also allow for the use of social network options (that themselves leverage protocols like OpenID Connect) as forms of authentication.

So to add a third participating site:

• www.socialnetwork.example: existing public-facing service that provides user authentication and attributes to other domains.

The IDaaS may serve as a protocol translation and message normalization point - the results of local and remote authentication may be diverse, but the resulting authentication and attributes shared with www.customer.example are normalized and under a single, static trust relationship with the IDaaS tenant.

Goals

Changes to user experience during authentication (e.g. an authenticator selector for local and remote factors) should ideally account for an intermediary performing business decisions, separate from the RP or OP sites.

The user experience impact of having the business logic on a separate domain needs to be understood based on the approach. For example, does a transparent single sign on (backed by authentication state) now turn into an authentication on every use? Does a credential selector gating access result in a consent dialog on every authentication request?

In some cases the IDaaS product may support custom domain registrations (e.g. auth.customer.example), however this is unfortunately an atypical deployment strategy due to the need to go through a domain ownership vetting and to acquire/maintain TLS certificates. Unfortunately, migration between origins can break some existing authentication systems (Web Authentication). Do loss of functionality and impact on user experience result in custom domain registrations becoming a requirement? If so, we will need migration strategies or new features in protocols like Web Authentication to mitigate them.

"Log out" systems may have additional complexities under such a system, such as the need to 'fan out' a logout signal through multiple levels of issuance. If this is done through say front-channel javascript events, additional 'logout' may need to be invoked by an intermediary when an incoming 'logout' event is received, without requiring e.g. a user interaction.