2

Does OpenID Connect support the following SSO-like scheme:

  • Both website S and some meta-website M support login using OpenID Connect, e.g. with a Google account. Is it possible for M to access a user's data at S, with the user being authenticated for both services with the same 3rd party account (e.g. Google)? So M should be able to make authenticated requests to the API of the website S, with the identity of a user logged in with e.g. his Google account.
  • If yes, how would the workflow look like? (interactions between the involved parties, tokens to be obtained, ...) If not, are there other technologies which should be used for this case?

What I found so far, was to how to let a user authenticate at M using his/her account at S, but not using the account at another, 3rd organization.

  • is M(Server) or M(Client) trying to connect to S? Does M use the same ClientID and Scope as S while authenticating with Google? – JOW Mar 30 '16 at 15:56
  • I'm interested in the case when M and S belong to two different organizations, so they don't use the same ClientID. M posts API requests to S, either backend-to-backend, or browser-to-backend; both could be of interest. – mh8020 Mar 30 '16 at 18:26
1

NO

because the Session_State value(which is used to manage the session) is initially calculated on the Google's server. It is calculated by a salted cryptographic hash of Client ID, origin URL, and OP browser state. Since the Origin URL will be different between M and S, the same Session cannot be shared between M and S.

OpenID Connect Documentation here

  • OK. But would the following work? 1. User logs in at M (e.g. with Google account), 2. M requests authorization via OAuth2 at S, 3. user logs in at S with Google account (or at any other OpenID Connect identity provider), 4. user authorizes M's request, 5. M can use the API of S, having access to the user's data. Since OAuth2 does not specify how to login, it should be OK for the user to login at any identity provider, if S supports this? – mh8020 Mar 30 '16 at 18:47
  • this might work but the complexity is getting out of hand. Let me rephrase: M(back-end) wants to access certain Data in S and since you are willing to setup an identity server at S, then "Authorization Code Flow" type of OpenID Connect flow is used between M(back-end) and S. Other identity providers are used to authenticate users on both M and S. – JOW Mar 30 '16 at 21:12
  • 1
    Yes, my idea was to reduce the number of accounts required by the user. Thinking about it, this scenario seems to result in multiple redirects in the browser, leading to confusion => Probably not a good idea. It seems easier if S itself is an identity provider, and M allows their users to login with their S account. – mh8020 Mar 30 '16 at 21:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.