idbrowserusecases / docs Goto Github PK

Web application RP1 and RP2 offer sign in/sign up functionality for users of identity provider IDP1, using any of the following:

• any OpenID Connect flow
• any SAML flow
• any WS-Fed flow
• any proprietary cookie based auth scheme

The user is already signing in RP1. The user navigates to RP2, and expects to obtain an authenticated session without any interactive prompt.

User agent access to user info depends on the mechanics of the protocol of choice.

Obtaining an access token via local code+PKCE, refresh token.

Classic OAuth 2.0 flow meant to get an access token on the app backend, that does NOT result in a RP session (but will create/leverage a AS/OP session).

[Code | implicit] + prompt=none in an iFrame.

The details of the flow vary depending on protocol (OIDC has an extra full redirect round trip while SAML is effectively just one x-site navigation). But typically a user with a currently authenticated session (which likely maybe was established via SSO itself) is presented with a portal-like page with links to applications they can access. Navigating to one of those applications kicks off the IDP initiated SSO flow that ultimately delivers a SSO token to the RP application and the user is, from their perspective anyway, signed in seamlessly. I don’t think IDP-init uses browser features any more or differently than the SP-init variants (1st party samesite none/lax cookies and various things that look like link decoration). But it doesn’t fit the WebID model (last I’ve seen of it anyway) where the UX assumes things start on an RP site.

• Brian Campbell

Spec reference: https://openid.net/specs/openid-connect-frontchannel-1_0.html

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.

Classic API call with an AT (shouldn't have issues, but mentioned out of exhaustiveness).

Web application RP1 offers sign in/sign up functionality for users of identity provider IDP1, abusing OAuth2 (eg conducting an OAuth2 authorization code flow, attempting an API call with the resulting access token and considering the user signed in eg creating a session cookie if the call succeeds).

Ignoring how IDP1 authenticates the user, apart from the fact that successful auth results in a cookie in IDP1 domain.

Notable: the user agent doesn't see any user info, all exchanges occur server side.

Web application RP1 offers sign in/sign up functionality for users of identity provider IDP1, using OpenID Connect implicit flow and form_post.

Ignoring how IDP1 authenticates the user, apart from the fact that successful auth results in a cookie in IDP1 domain.

Notable: the ID Token might not contain user profile info, accessible via UserInfo call from the server (no user agent access) in case of hybrid variant.

Web application RP1 offers sign in/sign up functionality for users of identity provider IDP1, using OpenID Connect code flow.

Ignoring how IDP1 authenticates the user, apart from the fact that successful auth results in a cookie in IDP1 domain.

Notable: ID Token is obtained server side, no user agent access.

Apologies if this is not the best place to discuss this.

While the initial document version does a good job of summarizing the cross-domain federated flow, I'm not sure it goes far enough in capturing the potential user experience when browser state is limited. To provide a few UX examples:

Single Sign-on:

• Multiple different sites can participate in single sign on with only a single user authentication at IP1

Transparent SSO:

• IP1 may decide to not prompt for user consent if it recognizes the user has previously given consent to RP1

Transparent SSO as site integration:

• IP1 may use SSO across domains as a mechanism for integrating different pieces of functionality provided by different products (possibly under different hosting providers). Transparent SSO may be used to make services appear part of a single experience.

Anti-Phishing via Device Tracking:

• IP1 may have a security policy where the user must approve a browser (as a "new device") if IP1 does not detect the user has previously interacted from that particular browser.
• IP1 may provide notifications about unrecognized devices as security events
• IP1 may provide the user the ability to view different devices and activity if they are concerned someone has access to their account

To me, this seems better for guiding design - for example, device tracking is an example of a security feature which requires persistent ( and > 7 days) state, while transparent SSO is an example of a feature that breaks if every use of the browser API requires user confirmation.

Web application RP1 offers sign in/sign up functionality for users of identity provider IDP1, using SAML.

Ignoring how IDP1 authenticates the user, apart from the fact that successful auth results in a cookie in IDP1 domain.

Notable: the SAML assertion might be fully encrypted, hence opaque to the user agent.