Cross Domain Single Selective Sign In

前端 未结 4 2283
北恋
北恋 2020-12-28 10:58

Its not explicitly cross domain sessions that I am looking for, but its the easiest way to explain what it is I want.

I have a system which creates websites. The we

4条回答
  •  臣服心动
    2020-12-28 11:43

    OpenID provides some nice features, but unfortunately, the cross-domain behavior you're looking for isn't something that you'll find in a standard OpenID implementation. One of the primary design principles of OpenID is that the provider not disclose any information about the user without their explicit consent*, and so any reputable OpenID provider will never tell mysite-news.com that you've already logged in to mysite-blog.com without asking for user approval.

    [In technical terms, what's happening here is that mysite-news.com and mysite-blog.com are, conceptually, in the same security "realm", but OpenID identifies realms by URL patterns, and since they're on different domains they don't match.]

    And that doesn't give you the user experience you want. There are some previous answers that do a fine job of outlining the kind of system you need here:

    • Cross-domain login [...]
    • Transparent user session over several sites [...]

    In short, you'll be setting some sort of auth service on login.mysite.com to answer queries from mysite-news.com and mysite-blog.com. There are still a few ways you can take advantage of OpenID within this.

    1. The redirect-to-login-and-return-a-signed-token flow described there is exactly what OpenID does. So you could still use an OpenID implementation to do all that managing of signed tokens and replay protection, your client sites just get to skip the initial "discovery" part of OpenID and always redirect users to the login.mysite.com provider. And login.mysite.com gets to skip the step of "do I trust mysite-blog.com", because it's a special-purpose provider that can have its own whitelist of sites it always works with. OpenID would be purely behind-the-scenes here, users would never know that OpenID was somehow involved.

    2. login.mysite.com could, in turn, use OpenID to ask users to authenticate against their OpenID provider (whether it be Google or Yahoo or a specialist like myOpenID). From there it would look like a standard OpenID login and you'd get all the benefits, the disadvantage is that your login-redirect chain gets a little longer (and correspondingly slower). Them's the breaks.

    Good luck. This is a question that comes up fairly frequently, and I've yet to find a really great reference implementation that I can point people to, so if you find something good do come back and let us know.

    Lastly, obligatory link to Matasano Chargen's screenplay on the subject.

    [*] the recent Google Buzz fiasco is a good reminder of what happens when you surprise users about who their information is being shared with.

提交回复
热议问题