-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OAuth profile for FedCM #599
Comments
I just wanted to acknowledge and thank you for kicking this off @aaronpk !! I thought I was going to be able to read this carefully today and provide solid feedback, but other things got in the way. I skimmed through with joy but this deserves time. Nonetheless, I figure you should know that this is awesome and that we will be looking at this carefully over the next few weeks!! |
Updated 2024-06-20 I have gone ahead and did more mapping and experimentation As far as OIDC/OAuth goes, a lot of the authorization_endpoint request pipeline grants itself to be re-used at the id_assertion_endpoint. RPs would use w3c-fedid/custom-requests#2 to pass the required authorization endpoint parameters (sans the ones that we don't need anymore, from the top of my head that's redirect_uri, response_mode, state, but could be more) Note: Depending on the direction w3c-fedid/custom-requests#2 takes there is a new pipeline step necessary that transforms the FedCM request into oauth. It is also not possible at the moment to make use of all params we know and support1. This could be either www-urlencoded (i.e. what authorization endpoint POST binding already uses) parameter remapping to remove the prefix that current proposal has, or JSON body parsing where the fedcm API provided oauth params are in its own property as an JSON object (i.e. how we extract authorziation parameters from JAR) The IdP processes the request as per FedCM's requirements (e.g. checking Sec-Fetch-Dest), has to support CORS and then responds with either a successful response as it would usually depending on the response type, passing the response as a www-urlencoded string to the "token" that FedCM recognizes (e.g. Additional steps for FedCM:
The IdP can make use of FedCM's Continuation API should the authorization request pipeline deem it required. Further mapping specific to OIDC would be that FedCM The RP ends up with a standard OAuth Authorization Response in the credential that's parsed like so This mapping supports both public and confidential clients, allows RPs to re-use their The biggest hurdlea at the moment is FedCM-triggered IdP popup UI if the IdP cannot resolve the request straight away and has to use the continuation API to request permissions which may come as a second popup after sign-in (if button mode was used to also sign-in or sign-up), these popups come flying in on the screen, cannot have their optimal size defined by the IdP, and are generally a step down from a redirect based flow. On the plus side this actually means the RP can drop-in FedCM whilst also supporting browsers without FeDCM support with their existing response handlers since it doesn't change how the authorization response looks. Implementation notes: It is possible to reuse almost the entire authorization request pipeline, add the FedCM bits when the request's route is the fedcm one, remove state and redirect_uri handling and otherwise treat the request as an authorization endpoint request with a fixed FedCM-specific response mode. Endpoints acting as FedCM's accounts_endpoint, metadata endpoints, and optionally the disconnect endpoint seem to have no re-usable prior art and are at the implementer's discretion to handle as per FedCM's requirements, formats, etc. Footnotes
|
This looks great! I believe my LastLogin FedCM prototype essentially implements the OpenID Connect response_mode=id_token flow described at the bottom, except it's implied until w3c-fedid/custom-requests#2. I would gladly adopt the proposed interface. @aaronpk you know infinitely more about OAuth security than I do. In the case of LastLogin, which is a pure IdP (no additional APIs or OAuth scope), is there any security benefit to doing the full authorization code flow as opposed to simply returning the ID token and letting the browser pass it to the RP backend? Obviously this requires full JWT validation as you mention. |
One concern when trying to combine this with w3c-fedid/idp-registration#1. You could have some providers that implement only the authorization code flow, and some that only implement the id_token flow, and some that implement both. Would you have to have a separate type/variant for each combination in that case? |
The main differences between OIDC auth code flow vs response_mode=id_token are:
Yes, a type/variant would need to define an actually interoperable profile of OAuth/OIDC in order to be useful. |
I am morally and contractually obligated to reiterate that this is a long way from an actual "specification" :) But also say that this is super valuable work and thank @aaronpk again for doing it. |
hahaha yes. I did call it a "guide" twice in the first post 😉 |
ID tokens can be encrypted per spec but admittedly that's not widely supported. |
That would require a relationship between the IdP and the RP (or at least a fetchable JWKS at the RP), which I'm trying to avoid in my implementation for privacy reasons (#595). I realize this is a rather niche case, and currently not supported by the spec, but I'm hoping it ends up at least possible. |
I've updated my prior notes based on experimenting with the latest canary/available origin trials. |
I went and wrote up a guide for how I would recommend using FedCM with OAuth and OpenID Connect. You can find it here:
https://github.com/aaronpk/oauth-fedcm-profile
It's written more as an implementation guide than a spec, but I'm planning on eventually formatting it more like a spec.
At a high level, the summary is:
NB: This works equally as well with a plain SPA as the OAuth client, skipping all the backend parts I described here, where the JS code itself is the OAuth client. It can still use extensions like PKCE/PAR/RAR/etc. I just suspect the backend version to be the more common deployment, especially since the Browser-Based Apps BCP recommends running a backend to manage OAuth tokens when you're building a SPA front-end.
The text was updated successfully, but these errors were encountered: