On 14/05/2015 08:02, Kumar McMillan wrote: > > The goal: provide generic payment processing via Firefox Accounts > so that any Mozilla site can sell premium services. The user should > only have to log in *once* to purchase the product.
Just to be clear, are we talking about a special privileged flow that's only available to Mozilla applications? How would the flow differ if we were talking about payments in a third-party app that also uses Firefox Accounts for authentication? A (purely hypothetical!) example might be purchasing a premium Pocket subscription after connecting to Pocket via FxA. > Abstract user flow: > > - User decides to purchase 20GB more of Mozilla Backup storage for > $9.99 / month (just an example) - Click the purchase button - Sign > in with Firefox Account - Enter credit card information - Enjoy > enhanced storage Do you have a UX flow you could share to go along with this? I remember seeing some go past but didn't keep any links. > Implementation proposal: The below proposal will work and I think it'll be OK for privileged Mozilla<->Mozilla service coordination. But token sharing is indeed pretty scary, so I'd like to dig into the security properties here. > - On backup.firefox.com <http://MozillaBackup.com> , the click of > a purchase button begins an OAuth flow by requesting a code->token > with the scope ‘profile payments’ What's the purpose of the `profile` scope here? Is this for Backup's own internal needs so that it can get at the user's email address etc? > - backup.firefox.com <http://MozillaBackup.com> opens an iframe > (or redirect) to payments.mozilla.com <http://payments.mozilla.com> > and passes the OAuth token as a GET parameter We don't have APIs for it yet, but in general, at this step Backup might like to produce a narrower token having only the scopes that are relevant to Payments. Sean's working on the API as noted in: https://mail.mozilla.org/pipermail/dev-fxacct/2015-April/001422.html (Between trusted services we can get away without doing this, and we might decide that the payments processor also needs "profile" scope anyway. But it's an important step to think about in general). > - payments.mozilla.com <http://payments.mozilla.com> verifies the > token on the server and checks that it has the *payments* scope The key question here is: what power does a token with "payments" scope provide? If I were to somehow obtain a "payments" scope token tied to "[email protected]", what would the Payments system let me do on your behalf? Can I use that token to initiate new transactions using your stored credit card details without any further authentication? I suspect that it must grant this level of power, if we're to avoid a double-login scenario at all costs. That's a lot of power to put in the hands of the Backup app. So I feel like the security concerns here are less around sharing the token from Backup to Payments, and more around delegating that much authority to the Backup app in the first place. It that's not acceptable (which it certainly wouldn't be for a third-party relier) then we could try to come up with some clever extra step on the FxA side. For example, Payments could bounce you through a confirmation prompt on FxA, which proceeds transparently if you've got an active FxA session in that browser but prompts you to re-authenticate otherwise. Cheers, Ryan _______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
