3 ms·

Thanks for the expert feedback. From my very limited sec experience, I saw account_id in cookie, and identified that as a red flag. OTOH, I think a random token

by ovi256 15y ago

Thanks for the expert feedback. From my very limited sec experience, I saw account_id in cookie, and identified that as a red flag. OTOH, I think a random token in the cookie, identifying a server-side session that stores the account id, would be a good approach, as it's the classical HTTP auth implementation. For example, what the Rails tutorial describes [1]. For SSO, the other apps can ping the cookie-originating app: "Hey, who is this browser with this cookie token" ? [1] http://ruby.railstutorial.org/ http://ruby.railstutorial.org/

tptacek 15y ago
That's a fine approach, but developers push back on it because it requires all the apps in the SSO federation to be connected at all times. Most shops should just accept that requirement and get on with their lives, though.
route66 15y ago
This is more or less the way SAML [1] works, at least in one of it's protocols. The authentication server redirects (after successful login) to the initiating service and supplies an assertion-token, often with limited validity. With that assertion token more data can be asked from the servers to the auth-server directly. No account_id's go over the wire, the cookie needs only to be valid on the authentication server. And you should really need it, it's not much fun to implement. 1 http://en.wikipedia.org/wiki/SAML_2.0#Artifact_Resolution_Protocol http://en.wikipedia.org/wiki/SAML_2.0#Artifact_Resolution_Pr...