| title |
|---|
[]{#_rsg8k1ef0cpn .anchor}Atomic scenarios for identity in the browser flows |
This document captures the list of scenarios we believe should be described as part of this effort. Please refer to the corresponding issue entries for assignment and reference to individual scenario documents.
Web application RP1 offers sign in/sign up functionality for users of identity provider IP1, using OpenID Connect implicit flow and form_post. Ignoring how IP1 auths the user, apart from the fact that successful auth results in a cookie in IP1 domain. Notable: the IDToken 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 IP1, using OpenID Connect code flow. Ignoring how IP1 auths the user, apart from the fact that successful auth results in a cookie in IP1 domain. Notable: IDtoken is obtained server side, no user agent access.
Web application RP1 offers sign in/sign up functionality for users of identity provider IP1, using SAML. Ignoring how IP1 auths the user, apart from the fact that successful auth results in a cookie in IP1 domain. Notable: the SAML assertion might be fully encrypted, hence opaque to the user agent..
[to the SAML people: do we need to document this?]
[to the MS people: do you still have many apps in the wild using WS-Fed?]
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.
Web application RP1 offers sign in/sign up functionality for users of identity provider IP1, 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 IP1 auths the user, apart from the fact that successful auth results in a cookie in IP1 domain. Notable: the user agent doesn;t see any user info, all exchanges occur server side.
Web application RP1 and RP2 offer sign in/sign up functionality for
users of identity provider IP1, using [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.
[[Sign Out / SM] SAML Single Log Out (SLO) · Issue #15 · IDBrowserUseCases/docs (github.com)]{.ul}
Would probably belong to sign in, but it's a session management technique.
Classic OAuth2 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).
[[AT] OAuth 2.0 Code Flow · Issue #17 · IDBrowserUseCases/docs (github.com)]{.ul}
[Code | implicit] + prompt=none in an iFrame.
Obtaining an access token via local code+PKCE, refresh token.
Classic API call with an AT (shouldn't have issues, but mentioned out of exhaustiveness).
[[AT] OAuth 2.0 JS bearer token usage · Issue #22 · IDBrowserUseCases/docs (github.com)]{.ul}