SSO & Federated Identity
SAML, WS-Federation and most proprietary Web SSO schemes have flows similar to these.
Case 0. User establishes TLS session, signs on with username/password (usually with form post, sometimes http basic auth) server takes down TLS for rest of session. [Should we worry about this case? Although password is protected from interception, there is no binding to rest of interaction allowing session hijack, interception of app data, etc. User sees lock during initial interaction and believes session is "secure." Usual logic is for performance, however unclear this is even true as most of TLS overhead is in setup (key exchange.)]
Case 1. User connects to Identity Provider (IdP), signs on, typically with username/password over TLS, but possibly w/o TLS, or via alternative such as onetime password from hdw token. User then clicks on link to Service Provider (SP) which may be in same or different domain as IdP. Generally user is unaware that distinct site is being accessed. (By design.)
Case 2. Like case 1 except user begins by clicking on link to SP. App site detects that no login has been done (typically via cookie) and redirects user to IdP. Idp does login as in 1 and redirects user back to SP. Second request is performed without intervention by IdP.
Case 3. Like case 2 except, IdP to use may vary for different users. SP first determines IdP to user (e.g. by asking user, querying service, redirecting to canonical location, etc.) then all proceeds as in case 2.
In an Identity 2.0 approach, rather than using multiple usernames/passwords to register onto a website, Identity 2.0 would allow users to use one ID (digital identity) associated with multiple representations (cards) of user credentials.
Case 4. User attempts to access a resource. Relying Party (RP) / SP returns its access policy (for example, user credentials in SAML format). An appropriate card/id, which matches RP’s policy, is selected locally by the user. Security token is requested from IdP and presented to RP.