We provide numerous online services. We're needed to build up something which supplies a fastOreasy experience for customers if they're moved in one service (on
domain1.com) to a different service (on
It is possible to safe and sound method to instantly login a person instantly once he's been moved towards the cool product?
Yell at me when the solution below is totally insecure/wrong.
I was thinking about something much like that provided by a few online services for password recovery - they're e-mailed a hyperlink having a unique hash which expires, that enables these to change their password.
domain1.com would produce a unique hash and store it inside a database using the hash associated with a person together with an expire datetime area.
The consumer is going to be moved to
domain2.com would next create a request to
domain1.com using the hash to find the details about the consumer.
domain.com would then take away the hash in the database.
domain2.com would log the consumer in and hang cookie etc.
Could something according to OpenID or OAuth attain the same results?
Single sign-on (SSO) is conceptually really quite simple.
- User hits
domain1.comsees there is no session cookie.
sso.compresents login page, and take qualifications
sso.comsets session cookie for that user
sso.comthen redirects to
domain1to some special url (like
ssologinURL consists of a parameter that's essentially "signed" through the
sso.com. It may be as easy as a base64 of encrypting the loginid utilizing a shared secret key.
domain1.comtakes the encoded token, decrypts it, uses the brand new login id to sign in the consumer.
domain1sets the session cookie for that user.
Now, the following situation.
- User hits
domain2.com, which follows
domain1and redirects to
sso.comalready includes a cookie for that user, the same is true not present the login page
domain2.comusing the encoded information
domain2.comlogs within the user.
This is the basic principles of the salt water evaporates. You may make it better quality, more feature wealthy (for instance, this really is SSOn, although not SSOff, user can "log out" of
domain1, but nonetheless be drenched directly into
domain2). You should use public secrets for signing qualifications, you could have demands to transfer more details (like authorization privileges, etc) in the SSO server. You could have more intimate integration, like the domain names routinely checking the user continues to have privileges in the SSO server.
However the cookie handshake through the browser using redirects is paramount foundation where many of these SSO solutions are based.
If a person could play guy in the centre and grab that hash, would they have the ability to steal the mix domain transfer? Clearly it must be produced and delivered to the customer just before them requiring to make use of it. So say for example:
I am playing guy in the centre spying on Jack.
domain1.com which in turn causes a hash to be ready and delivered to him to ensure that when he accesses
domain2.com he is able to send that hash as authentication.
Because he accesses
domain1.com, his request comes through me, you return the page, I grab the hash and allow him to keep on.
domain2.com while using hash, you've now allow me to into
domain2.com and erased the hash.
He's none the smarter until he tries to login to
domain2.com and it is told that his qualifications are no more valid.
How can you overcome that?