We use one primary web app that was built internally and 3 other web apps that we did not build but that we do host. I want users to only have to sign into the primary web app, which uses Google auth. The three other web apps only offer username/password, but all 3 have an API. We have run a proof of concept of the following design and I'm interested if I've missed any big holes. The workflow:

  1. User signs into the primary web app (APP A) using Google auth
  2. The user clicks a button in APP A triggering SSO to one of the secondary apps (APP B)
  3. APP A makes an ajax request to its API asking for a valid password for APP B
  4. APP A's API calls APP B's API and resets the user's password to a new randomly generated, long, complex password THAT IT DOES NOT STORE
  5. APP A's API returns the new password to the browser
  6. The browser fills that password into the password field of a form that is a copy of the login form for APP B
  7. The browser posts that form to the login url of APP B
  8. You are now logged into APP B

* All requests are sent over HTTPS

The reasons we want to do this:

  • User's don't have to remember or type 4 passwords
  • Passwords will change frequently (on every login)
  • There will never be any weak passwords

I'd love your thoughts on the process, and if there are any major security holes I'm missing.


  • I can't see your code, so I have no idea. Also, what happens if someone steals the cookie and session? – Mark Buffalo Nov 3 '15 at 1:07
  • What exactly do you mean by "Google auth"? Do you mean Google Authenticator? – paj28 Nov 3 '15 at 1:55
  • How does App A's API authenticate to the API for App B (or the other two subsidiary apps)? If that mechanism is insufficiently robust it sounds like an attacker who could take advantage of that could just tell App B to reset its password to whatever the attacker liked. I would also take a very careful look at the sequence of events between the point where each new password is generated to the point where App B receives the password submission from the browser, for the potential of stuff like password leakage over insecure traffic or due to interactions with other code running in the browser. – mostlyinformed Nov 3 '15 at 3:32
  • Your specific implementation is different, but the answer is the same: since you have some form of control over B, use something like OpenID or SAML2. Even better, log into B via Google since that's already your authentication. – Jeff Ferland Nov 3 '15 at 3:41
  • @MarkHulkalo while stealing cookie or session is possible that isn't introduced by my workflow correct? That was inherent in the original password based login of the apps. – kevinob11 Nov 3 '15 at 3:47

Browse other questions tagged or ask your own question.