Securing an HTTP API - No user password prompt and avoiding exposing the private key

Question

I'm working on API exposed over HTTP that will be consumed by partner companies and deployed to their numerous clients.

In some cases the client will be browser based. This is my major focus but I could potentially apply the same pattern where the client is a windows application. I feel that there is greater scope to secure a private key on the client when it's a windows application versus a browser based application. So the communication taking place is from a browser page rendered by the Partner application to our server where we host our API.

Bottom line is we cannot prompt the end user for credentials and must rely on a stored password/key/token that will be passed with each request. My concern is that I want to discourage the partner company from baking this token into client side code. The following is a high-level description of the scenario.

1. The partner establishes an account with us (a manual process), performs the necessary development work to consume the API in their product and then rolls it out to their clients.
2. The client then runs the product and works through a wizard establishing their account with us. We can prompt them for a username and password at this point but then all future requests to the API should never prompt the actual end user for credentials.
3. They then perform a myriad of business processes that invokes our API on many workstations under many different user contexts. We're not concerned with the individual user information.

For the purposes of this question I'm going to skip step 1 and focus on step 2 and 3.

I'm currently working to secure this API and have come up with the following design:

• HTTPS everywhere (all requests use SSL/TLS)
• All POST requests utilize CSRF tokens
• In step 2 when the client creates an account we provide them with a Client Auth Code. The partner should code their application to store this auth code on the server.
• Before future calls to our API they invoke an Init function on our javascript library and supply a callback, something like "GetAuthToken".
• On each call to our API we check if we have an Auth Token (on the server), if not we return an error and invoke the callback.
• The partner when implementing the callback should make a call to their server using HTTPS to retrieve the token. This request would be subject to their normal authentication so the assumption is that if the user is authenticated in their system then they can retrieve the Auth Token.
• We receive the Auth Token, make a call to our server to validate it and then set a HTTPOnly cookie containing the token.
• When the cookie expires we call the GetAuthToken callback again.
• Cross domain issues are managed using postMessage
• We can make the Auth Token revocable

We have a form of federated security here, if the user is authenticated with the partner then we assume they have access to our API. The only way I can think of to avoid baking the private key/auth token into the client side code is this callback mechanism.

Am I over complicating it? Are there other simpler approaches? I realize if either site is open to XSS or compromised by malware all bets are off but at least by not rendering the private key into javascript or markup the user can't right click view source and tell everyone the private key.

Edit: Found this question. The top answer describes something similar to what I described although mentions WIF which I don't want to force the Partner to implement (they may not even be running Windows). Would still like feedback on my approach though...

Web Application - User Authentication Across Domains

Answer 1

I know you are asking for simplifications but have you gone down the road of exploring SAML federation where each partner asserts their identity with you when they launch the app, and you cookie them with your auth token? It avoids JS being involved at all and in conjunction with SSL + CSRF tokens puts you in a good place.