Related to #147 and the referenced bugs in that ticket. Also #45.
The default account ID provided by /oauth/authorize is un-resettable unless I pass in an account ID of my own; this isn't ideal for first-time logins / secondary account creation.
User A authenticates with Facebook, everything's good. He logs out of the app, passes his machine over to user B so that they can give the app a shot; since the session cookie is the same, both accounts become connected after the call to /oauth/authorize.
User authenticates with Facebook. He logs out, and tries to create a secondary account with GitHub. Since the session cookie is the same, both accounts become connected after the call to /oauth/authorize.
Everything works as anticipated if I delete the API's cookies; I can create an account, clear cookies, and get the same ID when I re-login with a given service, or create a new one and get a fresh account ID. So can we add a deauth/logout service that destroys the API session?
Apologies for the ticket if I'm missing something here, and thanks for all the great work guys!
This exists, but is not documented anywhere. Sorry about that; I've made a note to add it to the docs.
@jparkrr : Awesome, thank you!
Since this includes a redirect URI, I'm taking it the idea is to present the above in the form of a link? Is there any way to do this with a server-side API call, so that I don't have to expose the token to the FE?
There could be another, more complicated solution, although I can't think of what issue exposing the access token to the user would create.
We do it this way because we are clearing a cookie that we set at api.singly.com.
I'll research some other solutions :)
@gcpantazis I just added a new flag that can be passed in on /oauth/authorize of &account=false that will force the authorize request to ignore any session cookies, would always be a login or signup action then. This works well when you track your own account ids and pass them back in in the same field during the "connect" to add services to an existing account.
Docs should be updated at https://singly.com/docs/authorization :)
@jparkrr I'm mainly concerned about packet sniffing attacks with either an exposed href URL on-page or a server redirect. I could put it behind SSL but I'd like to keep options open. The solution @quartzjer posted looks good to me though, verified in my app, working as expected.
Thanks again sirs!