7N/ Mapping FedCM to OIDC Capabilities / Heather F
Session 7N
Mapping FedCM to OIDC Capabilities
Session Convener: Heather Flanagan
Notes-taker(s): Heather Flanagan
Tags / links to resources / technology discussed, related to this session:
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Will create two sequence diagrams, showing OIDC login and then showing where FedCM overlaps
FedCM makes a trade off between exclusivity and control (there is less control). The login session described in the diagram is purely login; we need to be able to destroy the cookie in logout, and that might be where we’re hoping FedCM might help or be called or something.
One concern is that since the user will want a consistent look and feel; while FedCM might not be needed in every scenario, we want the same UX.
FedCM: One option (considered less than ideal because all the RPs would have to change, and there are more RPs than IdPs) if you could change all the RPs so they use JavaScript instead of sending a 302 HTTP call and send a subset of current info. The JS constructs a permission prompt in the form of an account chooser. Right now, FedCM doesn’t deal with scopes or selective disclosure.
If you are unable to provide scopes, the code won’t actually be the same. The line to the authorization server requires the scope. If you get back a code from FedCM, it wouldn’t represent the same thing that they currently get back from the authorization server. Scopes aren’t just filters to attributes. They are messages to authorization servers that can have many outcomes.
As result of this exercise, there is an intersection only in the first part of the flow shown, and in the logout. FedCM will be less expressive. If you don’t want to use top-level redirects, you should be able to use a JavaScript call instead.
Consent dialogues are going to double; the AS consent may have more detailed requirements as per regulation than the consent being asked by the browser.
The FedCM overlay does assume you’re already authenticated and have active sessions. If there isn’t an active session, there should be a URL to log into an IdP.
FedCM seems to be most concerned about the IdP and logging in, but the RPs are more interested in other things because what’s most important is what happens after authentication; if the RPs have to change infrastructure just for authentication, that’s a harder sell.
One gap is that depending on where you’re going at the RP, there may be different security requirements (e.g., different authentication context). Maybe this can be handled by a code coming back from the Authorization Server that requires re-authentication. The first cookie let’s you find out there’s a session; after the browser collects all the authentication it needs, all shields are lowered. The entirety of what else is in the initial request gets added after the browser consent flow. FedCM is asking for consent before they actually have an active session. Think of it perhaps as registering the IdP session with the browser, setting up their account chooser.
There is an infrastructural sign in with an entity, regardless of where you want to go. User will have to register on every browser instance.
Concern about the enterprise scenario where the identity of the IdP is determined by the RP. Signing into Workday from Okta is an example of this. It’s a significant number of RPs that are using OIDC, but not a significant number of global OIDC accounts.
The RP can provide a list of authorized Authoriziation Servers in the JS call. If the clientID changes from one session to the next for the same user (effectively a different IdP each time) this will result in a bootstrap problem every time.
FedCM isn’t making OIDC requests; it will contain some of the information in an OIDC flow. What semantics is the IdP using if not OIDC?
We need a third endpoint in the Authorization Server side (e.g., account.google.com)
The code that’s listed might not be the same between OIDC and the JavaScript. In order to get the code needed for the Authorization Server, might need a new ceremony.
There will be enough infrastructure work on the Authorization side that we may need to consider incentives. It’s also not a great UX because of the multiple prompts. But it will allow for things like front-channel logout, and is a ceremony-based account user that will future-proof you against further bounce tracking mitigations.
Some concern that this will look to a user like a phishing attack.
See image(s) for these notes in the IIWXXXIV Book of Proceedings here:
