yi-gu
commented
1 year ago Updated on April 25: Proposal with Mediation Requirements
Credential Management API supports handing over credentials to API caller automatically when certain conditions are met. It's achieved by using the mediation requirements field. We believe that it fits well with the FedCM use case. i.e. the browser can help to reduce user friction at the re-authentication moment for RPs/IDPs without paying such security cost. In addition, since the new streamlined re-authn experience only applies to returning users who have granted permission for the RP-IDP communication in the past, we believe that this can be done without reducing privacy.
A quick overview of how the proposed “auto re-authn” works:
- Prerequisite: a user has already created an account on rp.example with idp.example in the browser, and has not cleared site data for either site
- When the user returns to rp.example, they may no longer have an active session with the RP. e.g. 1P session cookie expired
- If “auto re-authn” is available (see details below), instead of showing the explicit sign-in UI with the “Continue as” call-to-action button, the browser can automatically fetch the token from idp.example and return it to rp.example
- If successful, the user will be automatically re-authenticated into the RP. The browser can display some UI in the “auto re-authn” flow to give users some context of this feature.
Proposals
Auto re-authn is for “returning users” only. In addition, it’s gated by several other conditions. We define “Auto re-authn is available” if all the following are true
- An RP has opted in to auto re-authn AND
- Only one account is eligible for auto re-authn AND
- User has not explicitly signed out from RP AND
- User has not disabled auto re-authn in browser settings (if provided)
Auto re-authn flow overview
Mediation Requirements
In the initial launch of FedCM API, we did not include the mediation requirements field which is part of the upstream Credential Management API. One of the goals of “mediation requirements” is to automatically share credentials with the API caller when certain conditions are met. Given that it meets the product requirements of FedCM auto re-authn and it has been used by Password Credentials, we believe that implementing mediation requirements for auto re-authn could not only complete FedCM API but also ensure consistency across similar products.
An RP can specify that they’d like to use auto re-authn by using proper mediation requirements in the existing API:
const cred = await navigator.credentials.get({
identity: {
providers: [{
configURL: "https://idp.example//fedcm.json",
clientId: "1234",
}],
},
mediation: 'required|optional|silent'
});In particular:
- mediation: ‘required’
- A FedCM UI will be shown to users to ask for their explicit permission to continue
- mediation: ‘silent’
- If auto re-authn is available (see definition above), trigger the auto re-authn flow. Otherwise do NOT show any UI
- mediation: ‘optional’
- Default value if not specified otherwise
- If auto re-authn is available, trigger the auto re-authn flow. Otherwise show a UI to ask for users permission to continue.
- mediation: ‘conditional’
- This is currently supported by WebAuthn. Only credential types with
isConditionalMediationAvailable=trueshould use this value. Otherwise the UA should throw a “TypeError”
- This is currently supported by WebAuthn. Only credential types with
Note: since the mediation requirements field is not supported in the current FedCM specification and the spec treats it as required, implementing the mediation requirement changes the default behavior of FedCM from required to optional.
preventSilentAccess
As mentioned in the Credential Management API specification,
The intent here is a signal from the origin that the user has signed out. That is, after a click on a "Sign out" button, the site updates the user’s session info, and calls navigator.credentials.preventSilentAccess(). This sets the prevent silent access flag, meaning that credentials will not be automagically handed back to the page next time the user visits.
By supporting preventSilentAccess, the browser can better respect the user's intent of “signing out of the website” by not re-authenticating them automatically.
Note that preventSilentAccess is an API that the browser exposes such that websites can provide the best UX with it. That said, it's up to the website to use it properly upon user signing out and the browser cannot enforce it.
Summary
When preventSilentAccess is not set for the RP
mediation / selected credentials |
single match | zero or multiple match |
|---|---|---|
| required | Requires user mediation | Requires user mediation |
| silent | Skip user mediation | Resolve promise with null / no prompt |
| optional | Skip user mediation | Requires user mediation |
When preventSilentAccess is set for the RP
mediation / selected credentials |
single match | zero or multiple match |
|---|---|---|
| required | Requires user mediation | Requires user mediation |
| silent | Requires use mediation | Resolve promise with null / no prompt |
| optional | Requires user mediation | Requires user mediation |
Privacy Consideration
The major difference between the existing authentication flow and the auto re-authn flow is that the latter does not require explicit user permission for authentication. However, an explicit user permission to allow the RP-IDP communication MUST have been granted in the browser in the past (e.g. the browser stores such permission locally after a previous FedCM grant). i.e. the new feature only works “post permission”.
From privacy’s perspective, this “post permission” feature does not introduce new privacy risks because an explicit user permission to allow RP-IDP communication has been granted in the browser in the past. Thus, bad actors can track user visits on an RP already. e.g. during the last time the user logged in with FedCM, RP and IDP could have already exchanged an identifier such that the RP could just make a fetch to the IDP and reveal relevant information to IDP anyway.
To align user expectations of whether they are logged into an RP, we propose UA revoking the previously granted permission when users clear cookies etc. for either IDP or RP. e.g. In Chrome, the permission gets cleared when a user clears Browsing history or cookies or SiteData in chrome://settings/clearBrowserData or chrome://settings/content/all (SiteData for either RP or IDP). i.e. auto re-authn won't work after such user actions.
mediation: silent
Per specification of the mediation: ‘silent’:
The intended usage is to support "Keep me signed-into this site" scenarios, where a developer may wish to silently obtain credentials if a user should be automatically signed in, but to delay bothering the user with a sign-in prompt until they actively choose to sign-in.
On the one hand, the key difference between silent and optional is that “RP prefers not to show any UI to users” if auto re-authn is unavailable when silent is used.
On the other hand, UAs may have requirements to show UIs in a FedCM API call to mitigate IdP tracking problem. e.g. Firefox shows an IdP selector before sending the request to fetch accounts from IdP; Chrome shows the account selector (and will show sign in to IdP UI or some error UI) after the accounts fetch.
We believe that it’s possible to respect both with the following proposal: when mediation: ‘silent’ is used, before fetching accounts, the browser can run several checks to make sure that we don’t fetch accounts if auto re-authn is guaranteed to fail. In this case, no UI needs to be displayed and no leak would occur:
- Check if a user has never granted permission on the RP with the IdP
- Check if a user has opted out of auto re-authn in browser settings
- Check if preventSilentAccess flag is set for the RP
Security Consideration
Technically speaking, the concept “auto re-authn” is achievable on the RP land. e.g. when a user is signing in to an RP with an IDP, the RP can set a long-lived cookie (e.g. 400 days) such that the user is always signed in to the RP as long as they revisit the RP within 400 days. However, while being able to automatically sign returning users back in is a promising feature for RPs, having to extend 1P cookies may be suboptimal or even impractical for some RPs. The proposed API on the other hand:
- provides all RPs the opportunity of “auto re-authn” without jeopardizing their cookie policy
- Having long-lived session cookies are hard because an RP has to deal with cookie theft etc. which gets proportionally harder the longer it lives
- It’s cheaper to operate by delegating it to the IDP (auto re–authn works when the user is signed in to the IDP, i.e. IDP needs to manage long-lived session cookies but RPs don’t)
- does not introduce any security risk similar to privacy since it’s “post permission”
Alternative proposal
Initially we proposed adding a new boolean autoReauthn: true|false to FedCM API to achieve the same goal but that requires reinventing the wheel which is suboptimal.
FedCM extensions consideration
IdpSigninStatus API integration
As part of the IdpSigninStatus API, the browser can be notified by the IdP that whether a user has an active session with them. If no user is signing in to the IdP when FedCM API is called, the browser will terminate the flow early before sending out an account fetch request. The same strategy will apply to auto re-authn. i.e. auto re-authn will be treated as “unavailable” if the IdpSigninStatus is signed-out.
Multiple IDP support
FedCM is adding multiple IDP support (explainer) which may have an intersection with auto re-authn. e.g. if both IDP1 and IDP2 are eligible for FedCM, how does FedCM handle auto re-authn?
Similar to the “single IDP with multiple accounts” use case, we can choose to trigger auto re-authn only if the user has one returning account across the IDPs. e.g.
| Account with IDP 1 is new | Account with IDP 1 is returning | |
|---|---|---|
| Account with IDP 2 is new | No auto re-authn | Auto re-authn with IDP 1 |
| Account with IDP 2 is returning | Auto re-authn with IDP 2 | No auto re-authn |
bvandersloot-mozilla
martinthomson
Bojhan
Currently, after a user has created a federated account on an RP with an IDP via the FedCM API, the next time they revisit the website they need to go through the same steps with the same UI affordances. i.e. they will need to explicitly and manually re-confirm to re-authenticate and proceed with the sign-in flow. This UX makes more sense before the user has created the federated account to prevent tracking, which is one of the main goals of FedCM API, but less so after the user has gone through it once: after the user grants permission to allow an RP-IDP communication, there’s no privacy or security benefit for enforcing another explicit user confirmation for something that they have already previously acknowledged.
We have heard from both RPs and IDPs that they would like the authentication experience to be more streamlined for users who have already created a federated account with them. In fact, there are already use cases on the web that are implemented with third-party cookies. From UA’s perspective, supporting re-authentication without explicit user confirmation can: