We are going to serve content to a Content Management System that embeds it through an
iframe (yuck). Some pages that we serve need to be authenticated before – only a valid user should be able to see them.
The company who previously implemented what we're about to do did this through the requests. Of course, since there was no session management. The use of
Believe it or not: One could easily get the content of another user by exchanging ID or e-mail. Now we want (or, have) to change that. The problem is that we do not have access to the customer data. We don't know e-mail address and user IDs of the CMS.
The initial plan that had been developed was to send us a salted hash with e-mail and ID, and somebody thought it was possible to extract e-mail and ID from the hash again if we knew the salt. Well, turns out they didn't know how hashes work… so it's on me to come up with something new.
Here is the first scenario I thought of:
In this case we only receive a list of valid hashes from the CMS and check if the hash the user sent us is valid. The problem here is that we need a list of hashes and the CMS needs to send them to our backend some way. Is there any other issue I'm missing? What about users trying all possible hashes?
We receive the user's hash and send it back to the CMS. The CMS verifies that this hash really exists and tells us whether we can serve the content. Here, the problem is that extra requests have to be made (performance?).
Third scenario – which I think should fit in our case:
The user sends us their e-mail, ID and the hash the CMS generated for them. We share a secret key (the salt) with the CMS, and try to reconstruct the hash from e-mail and ID. If it matches, the user must've been authenticated in the CMS before, so we can serve the content.
The problem here is that we send the e-mail via URL. Now, the previous (insecure) implementation also did this, but I don't know how much of a privacy issue this is.
Bottom line: Is there anything I've missed in the above examples? Would the last scenario fit our case, or is there another easy method to authenticate a user when you don't have access to private data on your side of the scheme?