So zaach and I were talking about this "covert redirect" issue (which we aren't vulnerable to), and what you might do to OAuth to prevent the whole class of problems. Part of the problem is that you're passing data back and forth between the RP and the authorization (OAuth) server *through* the user's browser. What if we removed that?
It might look like this: * user shows up at RP, wants to log in. * RP allocates a "state" token, sends a message to the authorization server. "Hi auth-server, I'm going to be sending a user to you soon. You'll recognize them by state=123. I want permission for the following scopes: A,B,C. I'll wait here for your answer.". The message would either be signed (Gryphon) or just include the client_secret. * once the authorization server acks the RP's message, the RP redirects the user's browser to the authorization server, passing only the "state=" value in the queryargs * the authorization server pulls state= from the URL to figure out which app wants what power. Then it has the user log in (if necessary), figures out which permissions must be asked about (e.g. not whitelisted), presents the questions (naming/describing the app), and gets the answers. It then sends a message directly back to the waiting RP with the resulting power-granting token (or Gryphon key). * when the RP gets their token and has it safely stashed away, it tells the authorization server to redirect the user to an RP URL * the user's browser gets sent back to the RP The RP would correlate the user's session cookie (established when the browser first visited the RP) with the state token. The RP could either hold open a TCP connection (maybe not HTTP) to the auth server while it waits for the user to finish the flow, or provide a callback/webhook URL for the auth server to ping once the user is done (in which case it should include state= to correlate it to the original request). The auth server waits for the RP to acknowledge receipt of the token before redirecting the browser back to the RP, so the user doesn't show up before the RP is ready. The return-redirect URL could be pre-arranged during app registration, or submitted with each request (since these RP-to-auth-server requests are authenticated, we avoid the attacks that require redirect_uri= to be pre-registered). The result would superficially look like OAuth to the user (same questions, same redirect-based flow), but the protocol would work very differently. The key change is the direct conversation between RP and authorization-server (before and after user actions), which may make it unsuitable for certain flows that OAuth2.0 tries to support, but might be enough for everything we're planning to do with it. thoughts? -Brian _______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
