Closed Yekongs closed 7 months ago
client_id identifies an RP, not a user. For example. google.com would issue a client ID to pinterest.com when they sign up for "sign in with google"; the same client ID is used for all requests from pinterest to google for signin.
See for example: https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/
client_id identifies an RP, not a user. For example. google.com would issue a client ID to pinterest.com when they sign up for "sign in with google"; the same client ID is used for all requests from pinterest to google for signin.
See for example: https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/
Got it, but what confuses me is how does FedCM implement single sign-on? For example, pinterest1.com and pinterest2.com are two different services, so the client_id they get from google.com should also be different, so the list of accounts obtained is different. How to achieve single sign-on in this case?
The client ID is not even send to the accounts endpoint, so it can't affect the returned accounts
The account list should only be based on the cookies for (in this example) google.com. It would presumably return all google accounts the current user is signed in to.
The client ID is not even send to the accounts endpoint, so it can't affect the returned accounts
The account list should only be based on the cookies for (in this example) google.com. It would presumably return all google accounts the current user is signed in to.
But in the demo, there is no code about cookies when returning the account list. Did the IdP return the full number of logged-in users, and then did the chorme browser help us filter it, or did the demo just omit this part of the code?
Which demo?
The accounts are normally not filtered at all, unless you provide a login hint.
The browser automatically sends cookies to the accounts list endpoint.
Thank you for your answer. https://glitch.com/edit/#!/fedcm-idp-demo?path=libs%2Fauth.js%3A162%3A0
Yeah, that identifies the user through a connect.sid
cookie.
Yeah, that identifies the user through a
connect.sid
cookie.
That is to say, users use FedCM to log in in two services successively, and their connect.sid is the same, so that IdP can know that the same user is logging in to different services, and then can return the same account list
Yes, although it is not really "their" connect.sid cookie, that is the IDP's cookie which does not change.
Is there anything actionable here that is still hanging? I'm going to close this since I feel like there isn't anything else we need to clarify, but feel free to re-open if you feel like there is still something actionable here.
How should IdP assign client_id, is it relative to each accessed service domain name or each device?