I am fiddling about with a sort of single sign on procedure. Let's say there is site1 and site2 and both use an SSL certificate. Users are signed in on site1. I was wondering what the experts think of this way to let users automatically sign in on site2 that is hosted on a different server:

  1. clicking on a link in site1 gets the url (on site2) and 2 codes from a database
  2. site1 redirects to the url (on site2) and sends the 2 codes as a post request
  3. Site2 checks if the page that is redirected from is really from site1 and if the combination of the codes are correct
  4. If so site2 creates a hash and stores it in the database and sends the result back to site1
  5. Site1 redirects to site2 and sends the hash
  6. if the hash is in the database and was received from site1 and within a short time after creating it the user is logged in.

Is this a (fairly) secure way for a signle sign on procedure or is this horribly insecure? If the latter: where do the dangers lie?

  • 1
    First of all, I hope you agree that home-made protocols may only be used for learning and never in production. So even if we told you that we see no errors, that would not mean you can use this on actual users. Regarding your idea: The description is very vague and obscure. Why two codes? How does site 2 check that “the combination of the codes is correct”? What does that even mean? What's the hash part supposed to do? Hash of what? I think this needs a lot more work if you want proper answers.
    – Fleche
    Commented Jul 25, 2014 at 10:54
  • 3
    You should look at OAuth and OpenID. They provide single log in AND have already been tested.
    – Gudradain
    Commented Jul 25, 2014 at 10:54
  • @Fleche: the 2 codes serve as a check so that no other site could try to access site2, they would have to know these codes (a bit like login/pw combination). the codes are known by site2, they can be stored in a file or db. The hash contains the actual login: it only remains valid for a short time so it should not be possible to crack it. I said 'hash' but probably 'nonce' would be a better name. @Gudradain": where would the fun in that be?
    – bolvo
    Commented Jul 25, 2014 at 11:07
  • @Fleche: maybe also add: this system is set up so that users could never see the url's that are used to log in, everything is done in the background, so it would be extremely hard (?) to figure out which url's to target
    – bolvo
    Commented Jul 25, 2014 at 11:20
  • @bolvo How are they, the 2 codes, known to site2 if it's site1 that generate them? Are they always the same? What protects you against replay attack if that's the case?
    – Gudradain
    Commented Jul 25, 2014 at 12:34

1 Answer 1


You simply state "site 2 checks if the page that is redirected from is really site 1"... how? There isn't a good way to do this without further information that site 1 can use to verify it's identity via a challenge from Site 2.

This also seems overly complex for passing an authentication. All that really needs to be done, as long as Site 1 and Site 2 both communicate with each other and know each other, is for them to agree between themselves on a token and redirect the user with that token so that one site knows it is the same user that was on the other site.

Don't roll your own, use OAuth or something similar, it will allow better integration with more sites and is also a well supported and tested standard.

  • I am not sure we are on the same page. Which password is given to a third party?
    – bolvo
    Commented Jul 25, 2014 at 14:50
  • Oh, I see, I misread your post. I'll update my answer momentarily. Commented Jul 25, 2014 at 14:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .