<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">There’s been a chat going on about login to the Payments flow in a manner that means users don’t have to login twice, but can just login in once to a site. The UX for that flow is here:<div class=""><br class=""></div><div class=""><a href="http://payments.readthedocs.org/en/latest/design/ux.html#purchase-flow" class="">http://payments.readthedocs.org/en/latest/design/ux.html#purchase-flow</a></div><div class=""><br class=""></div><div class="">We were having a chat in a thread and realized it should move to the public list. So apologies for that. Here’s basically what Ryan proposed in those emails…</div><div class=""><br class=""></div><div class=""> * User goes to Mozilla Concrete<br class=""> * User clicks Buy<br class=""> * User has to login on Mozilla Concrete, so:<br class=""> * Concrete uses the iframe lib to start the oauth dance<br class=""> * It requests scopes "profile+payments"<br class=""> * The user logs in as normal<br class=""> * The oauth dance completes and Concrete gets an oauth token<br class=""> * Concrete verifies the oauth token, extracts profile data, whatever<br class=""> * Mozilla Concrete then needs to send them onto buy<br class=""> * Concrete uses the payments iframe you provide<br class=""> * It passes in the oauth token as part of the call<br class=""> * Payments verifies the token to extract user and relier info<br class=""> * User is verified and lands in payment UI<br class=""> * Payment magic happens, notifications fire, whatever<br class=""> * (Actual) Profit!</div><div class=""><br class=""></div><div class="">I then drew a diagram, which is probably hideous and wrong:</div><div class=""><br class=""></div><div class=""><a href="http://payments.readthedocs.org/en/latest/design/design.html#purchase-flow-fxa" class="">http://payments.readthedocs.org/en/latest/design/design.html#purchase-flow-fxa</a></div><div class=""><br class=""></div><div class="">There were some security concerns that came up from that and Ryan also said:</div><div class=""><br class=""></div><div class="">"So the one comment I want to add here, is that we generally discourage<br class="">reliers from sharing their oauth tokens directly with others, since it<br class="">gives all the power and authority in that token to whoever happens to<br class="">possess it.<br class=""><br class="">We'll probably want to provide some sort of "token narrowing" API to<br class="">enable this in a more secure fashion.<br class=""><br class="">If for example, Mozilla Concrete has a token with scope<br class="">"profile+payments+SuperSecretOtherThing", then it doesn't want to pass<br class="">that token directly to other services. Instead, it could call some API<br class="">on the oauth server to generate a fresh subsidiary token with only<br class="">"payments" scope, and pass that token to the payments service.”</div><div class=""><br class=""></div><div class="">Any comments?</div></body></html>