dpb587
commented
5 years ago Thoughts...
- originally I implemented this as
POSTbecause I didn't/don't like the idea of credentials being in a query string. - I tried switching to
GETand it works. But the query string and auth token does indeed remain in browser history after restarting (tested Firefox). - Safari gives the mentioned error, but Chrome and Firefox seem okay and do not cause a prompt.
- switching to XMLHttpRequest with CORS headers seemed to half-work on Chrome. The request would go through, but Chrome reported it as a failure; also never seemed to send the initial
OPTIONSpre-flight; didn't really figure out that behavior. - switching to XMLHttpRequest to post the token would result in mixed content failures.
- switching to embedding a script with a query of the token would result in mixed content failures.
Options...
- ignoring the issue; recommending Chrome or Firefox (possibly aided by
auth.open_command) - multi-step cookie use: 1) server sets short-lived cookie with token; 2) redirect to client http; 3) client requests dynamic javascript from server to reflect the token from cookie; 4) javascript posts the token to client api. Might work, but this is relatively complicated and has potential ~CSRF concerns.
- provide option for CLI to use self-signed cert (allowing systems to add it to their trust store and avoid security warnings). Probably work, but is probably complicated if/when those certs go bad.
- client establish a backchannel to server to receive the token instead of relying on browser/client transfer. Works, until multiple servers are load-balanced at which point it requires shared state.
Random...
- in theory SAML has similar workflows, but real environments would never have IDP HTTPS -> SP HTTP where this would happen as well.
Interested in other ideas.
For example, Safari gives the following warning when redirected back from ssoca to delivery the token to the client.
It works okay in Chrome.