Is this SSO implementation secure?

Question

A client has asked us to devise a simple Single sign-on solution for their vendors. In this situation, the client has many vendors with the capabilities to implement a simple solution which allows the vendors' users to sign in to our client's site. I came up with this:

Shared data

The following data will be shared between us and a given vendor.

• user_id - Provided by vendor
• vendor_id - Provided by us
• vendor_secret - Provided by us. "Random" SHA512 hash

Shared hashing function

Our specification will define the following practice for producing a key that is suitable for transmission via URL parameters:

// Pseudo-code. Assume sha512() is a function in their native language that accepts a string and returns a SHA-512 hash
vendor_id = 341;
vendor_secret = "areallylonghash...";
user_id = "12345abcdef;&";
hash = sha512(vendor_id + ":" + vendor_secret + ":" + user_id);

SSO Process

1. User clicks "log in" on a vendor's site and a GET request is issued to the vendor's SSO entry point.
2. Vendor recieves request on entry point (Say www.avendor.com/sign_in).
3. Vendor uses hashing function above to generate hash for user.
4. Vendor redirects to our client's endpoint with the parameters vendor_id, user_id, and hash.
5. We receive a request at our endpoint. We look up the vendor_secret from the vendor_id passed and attempt to recreate the hash that was sent to us.
6. If the generated hash matches, create a session on the client's site.

Potential problems

If we're using a GET request for the redirection step 4 is it possible that the generated hash could end up in a user's browser history? Not very secure if someone can just click on a link in the history. Could we use HTTP headers to transmit the hash when redirecting?

If you've gotten this far, thank you. All feedback is welcome! We're like to make sure we're deploying a secure solution.

Answer 1

Answer: no, it is not secure.

In step 4, the user agent gains access to vendor_id, user_id, and hash. Now the client can append any string they want to the user_id and modify the hash to match. I'm not sure I fully understand your proposal, but it seems like this might enable one user to log in as another user whose username is a prefix of their own.

You need to use a HMAC instead of a plain hash.

Stay away from implementing your own crypto!

Answer 2

3(b) Vendor issues API request to your app with a generated token

3(c) Your app saves token with user_id

4() Vendor redirects with params user_id, vendor_id, token, hash

If token matches one from api, log user in, delete token

Then the redirect url is a one-time use

OR

Don't do an extra API request. Use time based rotating RSA key. Then the redirect URL only works for 5 seconds or whatever.