samuelgoto
commented
1 year ago One proposal, is to extend the FedCM JS API (with a parameter called “scope”) to introduce a signal that the user agent can use to distinguish whether to mediate or delegate authorization. When it delegates authorization, after the existing browser mediated account chooser, the user agent uses a pop-up window to load content from the IdP that can be used to gather the user’s authorization.
The existing browser mediated account chooser allows the browser to capture the user’s explicit confirmation / acknowledgement that the user’s intention is to sign-in/sign-up/continue to a relying party with an identity provider. This prevents a tracker from abusing this API, and maintains the privacy bar that FedCM has set.
The delegated IdP window allows the IdP to gather the user’s permission using its own words.
Architecturally, this is accomplished by the following algorithm changes to the FedCM execution:
Specifically, we propose to:
- Make a UX separation between account choosing and API authorization.
- Make the browser mediate account choosing (as it currently does with FedCM) and
- Extend FedCM to offer
- An extension to the FedCM JS API that allows the RP to say that it wants to use the delegated authorization UX to allow the IdP to mint a (or many) token (an opaque string that can carry things like access/refresh tokens, but isn’t opinionated about what goes in it) or errors back to websites through the FedCM promise.
- An extension to the FedCM UX to include a delegated authorization UX: a Window (i.e. a pop-up window with the (a) proper attribution (displays the URL of the content area) and (b) content from the IdP (i.e. HTML/JS/CSS)) that an IdP can control to gather the user’s consent using their own words.
- An extension to the response in the id_assertion_endpoint that the IdP can use to pass back a URL that allows the browser to open the IdP Window
- A JS API that RPs can use to refresh tokens using the IdPs cookies, that can only be called under the assumption that the user has gone through the mediated permission prompt that was gathered in step (b).
User Flows
In this proposal, our journey starts with a “sign-in with idp.com” button that is rendered by websites, in this case www.timeoff.com.
From this interaction, the website can use a newly introduced parameter to the FedCM API, called scopes, which is an array of opaque strings, to trigger the new flow:
partial dictionary IdentityProviderConfig {
// A list of strings that represent what the Relying Party needs
// from the Identity Provider.
sequence<USVString> scope;
// The types of tokens that the RP wants to get back from the IdP.
// More than one can be requested, e.g. an id_token and an access code
// token:
// https://openid.net/specs/openid-connect-core-1_0.html
// #code-id_token-tokenExample
sequence<USVString> responseType;
// A map of key-value pairs that are opaque to the browser and only
// passed to the IdP after the user's acknowledgement.
record<USVString, USVString> params;
};For example:
let {token} = await navigator.credentials.get({
identity: {
providers: [{
// A newly introduced "scope" attribute, a list of strings
// Defaults to "name email photo"
scope: [
"drive.readonly",
"calendar.readonly",
],
clientId: "1234",
nonce: "234234",
loginHint: "previous@user.com",
configURL: "https://idp.example/",
responseType: ["id_token"],
// A string with parameters that need to be passed from the
// RP to the IdP but that don't really play any role with
// the browser.
params: {
"IDP_SPECIFIC_PARAM": "1",
"foo": "BAR",
"ETC": "MOAR",
}
},
}
// If possible, return without prompting the user, if not possible
// prompt the user.
mediation: "optional",
});With this newly introduced parameter, the browser then knows that it should not mediate authorization but rather delegate it. It starts by going through the mediated FedCM account choosing flow, which can be customized for this specific case (e.g. we can show it as a modal dialog, etc).
The (modified) account chooser serves to gather the user’s acknowledgement that the intent is to “sign-in to website.com with idp.com”. With the user’s permission, (a) the browser gets confirmation that this was indeed the user’s intent and (b) introduces to the IdP the user’s intent to sign-in to the relying party for the first time.
After account choosing, based on the JS request scope parameter, the browser makes a determination: should the browser mediate the authorization for exchanging the user’s profile (is the RP asking only for the user’s profile?) or delegate authorization to the IdP (is the RP asking for OAuth scopes that the browser wouldn’t know how to formulate a question to the user?).
If the RP needs access to OAuth APIs, the browser makes an HTTP POST request to the IdP’s id_assertion_endpoint with all of the parameters passed by the RP. The IdP, with all of the information available (request parameters, etc), can make a determination on whether it has gathered sufficient acknowledgement from the user or not and it uses the response of the POST request to determine how the browser should proceed: if the response provided by the IdP resolves with a “token” parameter, the browser continues to resolve the promise without any extra necessary permissions (as per the usual FedCM flow), but, in the presence of a “continue_on” parameter in the response, the browser is commanded to ask the user for more information and opens a pop-up window with the value of the “continue_on” parameter.
For example, when the IdP gets the following POST request to id_assertion_endpoint:
POST /fedcm_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity
account_id=123&client_id=client1234&nonce=Ct60bD&disclosure_text_shown=true&scope=google-drive.readonlyThe IdP can now respond with:
{
// In the id_assertion_endpoint, instead of returning a typical
// "token" response, the IdP decides that it needs the user to
// continue on pop-up window:
// "token" : "eyJC...J9.eyJzdWTE2...MjM5MDIyfQ.SflV_adQssw....5c"
"continue_on": "/oauth/authorize?scope=..."
}With that response from IdP back, because the browser acknowledges that it doesn’t have the words to ask the user the question (i.e. the browser doesn’t know what the “scope” is), it delegates that task to the IdP by opening a pop-up window (the actual UX is user agent specific) with the right attribution (i.e. it shows the origin/url that is being served) by opening a pop-up window pointing the user to the “continue_on” URL. Because the browser has already gathered the user’s consent to release to the IdP who the RP is, it includes both the IdP’s first party cookies as well as the RP’s identity, which is then able to construct the necessary permission prompt using its own language:
When the IdP has gathered sufficient confirmation from the user that the operation is authorized, it calls a newly introduced JS API that tells the browser to hand it back to the RP (which the browser does by resolving the original promise).
// NOTE: this is only callable from the IDP's top level frame.
interface IdentityProvider {
// Provides the token back to the Relying Party.
static void resolve(token);
};For example:
document.getElementById("allow").addEventListener("click", async () => {
let accessToken = await fetch(`/generate_access_token.cgi`);
// Closes the window and resolves the promise (that is still hanging
// in the relying party's renderer) with the value that is passed.
IdentityProvider.resolve(accessToken);
// Closes the window.
window.close();
});With the access token back at the RP, and with the browser’s knowledge that the user has consented to signing-in to the RP with the IdP, the browser then has more context on the communication between the IdP and the RP.
For example, when a user returns to the relying party, the relying party has a choice of calling the FedCM API in “silent” mode, which refreshes the session if one was already granted, or fails otherwise:
let result = await navigator.credentials.get({
// Returns a result without any UI in case it is possible
// (specifically, only after the user has consented to the FedCM
// prompt in the past). Otherwise, returns an error.
mediation: "silent",
identity: {
providers: [{
// newly introduced "scope" attribute, a list of strings
scope: [
"google-drive.readonly"
],
configURL: "https://idp.example/",
clientId: "1234",
}]
}
});Which leads to the end of the user journey, signed-in to the website and having given the website all that it needs to operate.
Alternatives Considered
The most notable alternatives are on the opposite side of the spectrum:
- Full mediation (browser UI) and
- Existing Primitives (use existing low level primitives, e.g. window.open())
Which are covered in the next subsections.
Mediated API AuthZ
The most immediate idea that came to mind was to fully mediate the authorization flow. While that’s not entirely impossible, and shouldn’t be discarded, we quickly had an intuition that this approach would lead to (a) substantial amount of work to make it expressive enough within (e.g. a single IdP is already really complex) and across Identity Providers (i.e. make it representative of all of the IdPs product requirements) for (b) zero to no privacy/security benefits (e.g. with regards to keeping the privacy tracking bar) and, importantly, (c) ossification of the UI in the form of lack of extensibility (e.g. hold back the ecosystem to innovate).
Nonetheless, in this alternative, the browser would come up with a protocol to “get strings from IdPs” that can be embedded into templates in the browser UI. For example, in the following UI, the string “Calendar” is provided by the IdP (via resolving the scope parameter), but everything else is browser mediated.
While it is true that this could potentially make the browser more confident that the user’s consent was more explicit (the browser does control more of the UI, even though it does not know for sure what “Calendar” means – because that’s an IdP-specific concept), it suffers from a variety of extensibility and expressivity problems.
We haven’t ruled out this alternative, but we think the current proposal strikes a much better balance.
Existing Primitives
The second noteworthy alternative is to implement AuthZ entirely in userland with the existing primitives that are available, namely, window.open().
What’s most compelling about this alternative is that we’d reuse a lot of the existing APIs and not have to rethink the privacy/security properties of the new API surface. So, given the choice, this could be compelling because it would be the least amount of work that browsers would have to do.
In this formulation, it would be the website’s responsibility to request AuthZ after having asked for AuthN:
async function authZ() {
return new Promise((resolve) => {
const {token} = await navigator.credentials.get({
identity: {
providers: [{
// No extra parameters (e.g. scopes) to AuthN introduced.
configURL: "https://idp.example/",
clientId: "1234",
}]
}
});
// AuthN gathered, kick off the AuthZ flow now
// 1) Opens a pop-up window
const popup = window.open("[https://idp.example/authz](https://idp.example/authz?scopes=google-drive)");
// 2) Requests an "age" assertion from it
popup.postMessage("/request?scope=age");
// 3) When the user accepts, resolve the promise
window.addEventListener("message", ({data}) => {
// Gets the access token that was given back
resolve(data);
});
});
}While not something that we have entirely ruled out yet, this example shows some of the challenges: in the current UX flows, the RP only gets the response AFTER the use goes through the AuthN AND the AuthZ flow, whereas here, the RP would get “a” response right after the AuthN flow but BEFORE the AuthZ flow, and then “another” response after the AuthZ flow. Some of this can be mitigated by perhaps only allowing the IdP to call the API in this fashion (e.g. only allow this to be called from an iframe), but it raises some of these questions.
Extensibility
Interestingly, because the IdP gets to ask for the user’s permission using their own words (i.e. their own HTML/JS/CSS), the browser is entirely blind about what and how and why it is being asked.
We think that’s more of a feature than a bug.
For example, there are IdPs that could choose to ask for the parent’s user’s permission for under aged users (even when only the user’s profile is shared), and could lead the under aged user to pass the phone to their parents, which is something that would be close to impossible for a mediated flow to anticipate.
We think that having space in which IdPs can innovate independently without being pulled back by browser vendors can give a massive amount of autonomy to the ecosystem.
Open Questions
There are at least a few corner cases worth noting here: (a) we expect most users to have a single account (as opposed to multiple), so we need to make sure that the account chooser isn’t awkward in that case, (b) we need to deal with the case that the user is signed-out of the IdP and needs to be able to sign-in and (c) we need to introduce the ability for the user to add a new session when already signed-in.
These are problems that are generally independent of AuthZ per-se, but are are currently often used in conjunction with.
Single accounts Logged out users Adding other accounts
So far, we think that these are solvable problems.
martinthomson
alanbuxey
cboozar
bvandersloot-mozilla
letitz
cbiesinger
jonkoops
mitar
timcappalli
elf-pavlik
yi-gu
Identity Federation allows users to login to websites using their accounts from identity providers.
For consumers [1], for the most part (we estimate ~80% of the traffic), sharing your basic account profile covers the majority of the use cases, because it provides relying parties most of what they need to create an account: a signed and stable unique identifier and the user’s name, profile picture and email address.
However, occasionally, websites need more information about the user to operate: e.g. their schedule, their friends list, their amazon prime status, etc. The need for the different aspects of the user’s data varies greatly across websites and identity providers (e.g. some identity providers know their user’s email addresses, some don’t), so Identity Providers offer them an enumeration that they can pick and choose from to give websites access to HTTP APIs. The enumeration, encapsulation and addressing of APIs are known as “OAuth scopes” (e.g. we use, informally, “The website is asking access for the user’s Google Drive’s OAuth Scope” ).
For example, on rp.com, after choosing an account, the website asks specifically for the user’s “date of birth”, in addition to the user’s basic profile. The Identity Provider is happy to provide to the relying party as long as it gets confirmation from their users that that’s strictly necessary for the task that they are trying to accomplish (create an account on the RP, which customizes their user experience depending on their user’s age).
The authorization flows are currently built using low level primitives, like top-level redirects / pop-up windows / iframes / cookies (as you can see above), which are hard to distinguish from the same practices that have been abused for tracking. For example, at the end of authorization flows, the website gets an OAuth “access token”, which can be refreshed/re-issued using iframes and third party cookies. As browser vendors impose constraints in these low level primitives, we expect parts of these flows to break.
The Problem
The problem is that, as browser vendors increasingly work to prevent tracking on the web, they struggle to distinguish federation from tracking, and so unintentionally affect these flows. We call this “The Classification Problem”: it is hard to distinguish federation from tracking.
Thankfully, through FedCM, browser vendors are starting to find ways to solve “The Classification Problem” for at least common parts of the flows: authorizing the access of the user’s basic profile information, which we’ll call Standard Basic Profile Authorization Process for now (Authentication is sometimes used here, but that seems overloaded and inconsistent to us).
This is currently accomplished by mediating two flows: (a) account choosing and (b) authorizing access to the user’s profile:
FedCM managed to do that because (a) there is a lot of uniformity in account choosing between IdPs (e.g. how to represent an account) and (b) there is a list of well-known attributes (OIDC’s standard claims and HTML’s autocomplete ontology) of the user’s identity that can be requested (names, email addresses, profile pictures, etc), so it was plausible to anticipate and build a mediated Authorization flow to exchange the user’s standard profile.
However, beyond account choosing and the standard profile, there is an unbounded number of APIs that an Identity Provider can provide to Relying Parties.
For example, the browser would never be able to know how to ask the user for permission to access “Social Graph” because it doesn’t know what a “Social Graph” is (whereas it can, and indeed does, know the fields of the user’s basic profile: “name, email and profile picture”).
So, what worked to mediate authorization of the user’s standard profile doesn’t seem like it would work for authorization of the user’s identity more generally: IdPs need an extensible mechanism that allows them to express the authorization using their own words.
So, how should the browser allow IdPs to share with the RP more of the user’s data, without lowering the privacy properties of FedCM?