I’m logging in users via REST in my .NET application. For that in the WebBrowser control constructor I do the following:
string server = "https://login.salesforce.com/"; var authURI = new StringBuilder(); authURI.Append(server + "services/oauth2/authorize?"); authURI.Append("response_type=code"); authURI.Append("&client_id=" + clientID); authURI.Append("&redirect_uri=" + redirectURL); webBrowser1.Navigate(authURI.ToString());
This works fine, the user is being presented the standard sfdc login screen, he/she logs in, I do all the flow to get the security token and the user is able to work with SFDC.
Interesting stuff happens after the user logs out, and tries to log in again (e.g. under a different name). He/she clicks the login button, the code above runs again, but instead of showing the SFDC login UI again, salesforce just logs the user in automatically and redirects to the RedirectURI, kicking off the login flow. Thus the user has no way to log in under different credentials…
I was sure it was because of some cookie SFDC leaves behind, but after deleting all the cookies the user still gets logged in automatically…
When you use OAuth2 in a web browsing context, two things happen: (1) the user has to log in to salesforce.com and receive a “sid” (session ID), then (2) the user has to authorize the app if it is not already authorized. What this means is that the user is logged in twice, once with a session ID, and once with a access token.
As long as any browser process from that browser is active, the “sid” cookie will remain valid, up until the point where the sid expires from a session timeout (specified under security controls, session settings). Presumably, your logout function calls /services/oauth2/revoke, which you presume is logging out of both sessions, but is really only revoking the oauth2 access token.
You can prove this by going to your web browser, and visiting your salesforce instance’s /home/home.jsp page after logging in from your app; you’ll magically be logged in with no prompt. Conversely, log in to salesforce.com, then call your oauth2 login logic…
Here are a few workarounds. Some are kind of destructive (as in, they’ll be logged out of salesforce.com if they’re working in a browser window…), but you can try them out:
Call /secur/logout.jsp before presenting the oauth2 dialog. This will log them out of their browser, which may prevent them from automatically logging back in (or, it might just select a different user they’re logged in to recently…).
Call the multi-site logout page (the link presented on the OAuth2 grant authorization page that reads “Not you?”) before attempting to display the OAuth2 dialog. This will log them out of all instances of salesforce, and is probably not user friendly. I don’t have this link handy, but should I find it shortly, I’ll update this answer.
Figure out how to invoke Private Browsing on the web browser, or an entirely separate browser process, which should create an isolated cookie context. I did a brief search on Google, but didn’t come up with a relevant link for this solution. I presume it is most likely possible, I just don’t know how. You could probably load MSHTML.dll into your process space and manipulate it directly as an isolated browser process.
Detect the browser’s process and manually delete all salesforce.com cookies, then restore them afterwards (to prevent logging them out of their browser as well). I’m not sure this is easy, or even entirely possible, but you might find something on this path as well.