2

I'm working on an app that is planned to be licensed to OEMs, who would in turn offer it as a service to their users.  We would host the app server and the OEM would optionally host the app's web client.  Because of this we want the option for OEMs to allow users to authenticate through the OEM, using their existing credentials, without requiring that they make an account specifically for the app. 

I have one idea for how to accomplish this, but I feel like there should be a better way. In brief, the client sends an authorization token to the app server on behalf of the user, identifying them and the OEM they've authenticated with. In slightly more detail:

Upon obtaining a license for the app, our server and the OEM server negotiate a shared secret string.  (I'm not sure yet if the shared secret should be dictated by us, or chosen by the OEM with a minimum length requirement.) When a user who has already authenticated with the OEM first loads the app, the client sends an AJAX request to the OEM server asking for an authentication ticket, and then passes it on to the app server with a POST request.  This ticket has the parameters

userID, oemID, timestamp, token, digest

where oemID is a string representing the OEM in question, token is a random value generated by the OEM server, and digest is the base64 string encoding of

HMAC( sharedSecret, userID"|"oemID"|"timestamp"|"token )

The app server checks the timestamp to see that the ticket is still valid, then gets the corresponding shared secret for the given oemID and uses it to hash its own digest. It then hashes both digests again and compares them to each other. If they both match, the app server concedes that the request came from an authenticated user in the OEM's client, and sends a session cookie to the user's browser and stores userID and oemID in the session store. to uniquely identify future requests from that user. (We can assume userID to be unique from a given OEM, but not universally, hence using both.) This entire interaction (and all activity in the app) takes place over HTTPS.

Mostly I'm concerned that this system feels kind of hackish, but that might just be because most of my prior experience with authentication systems has involved plain old login pages, or made use of libraries that abstracted away essentially all of the work. Is this scheme essentially viable, or are there any clear problems or areas for improvement? Is checking the ticket digest enough to trust the initialization message? Does it actually make sense to implicitly trust the OEM server, or is there some motive and means for them to undermine the authentication process in a way that would affect more than their own users? Mostly, does it leave out anything glaring?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.