OAuth 2.0 back end service clients

[ckarlof]

We're starting to have the need for flexible, scalable, and secure server <-> server communication.

Here are some examples:

• FxA/Basket API integration: mozilla/fxa-auth-server#786
• Getting the uid associated with an email: mozilla-services/loop-server#183 (comment)

A related issue is helping with Marketplace's migration to FxA.

These endpoints need authentication and permissions. I think that our OAuth infrastructure can help with this, and what I'm thinking of looks similar to Google OAuth 2 service accounts.

Service providers could generate JWT assertions to the OAuth server that request a token that grants access to certain scopes (i.e., backend endpoints). For example, if the FxA Auth server needs to notify the Basket API of a new FxA user, it would request a token from the FxA OAuth server with scope service:basket and use this to authenticate the request rather than current API key in use. Google service accounts use Bearer tokens, but we could explore Gryphon public keys here as well to authenticate the actual resource requests.

[seanmonstar]

👍

[rfk]

Marking this "ready" as we're going to want it sometime in Q2. See related discussion in mozilla/fxa-auth-server#901 (comment)

[almet]

We have a use case for service to service authentication: payments.

• As the payments app, I want to submit new payment information for agivenuser and a specific selling app to the storage;
• As the selling app (e.g. "Mozilla concrete, selling concrete bricks"), I want to be able to access (readonly) the purchase information for agivenuser for my application.

So, the payment application and the selling applications will all need to get access tokens to send data to the storage API.

[rfk]

A bunch of OAuth/JWT-related RFCs when final recently; we should implement in line with them rather than doing our own thing. Example: http://www.rfc-editor.org/rfc/rfc7523.txt

[rfk]

Taking this out of "in progress" for now, we should revisit it as a user-story as part of the new dev process.

[seanmonstar]

Hm? Didn't Payments just mention wanting this this quarter? https://mail.mozilla.org/pipermail/dev-fxacct/2015-August/001675.html

[rfk]

Sorry, I don't mean to take this off your stack entirely, I should have said more words:

"""
we should revisit it as a user-story as part of the new dev process, and make sure it's appropriately scheduled into this quarter
"""

[rfk]

@billmaggs this is the additional context for the "backend service tokens" work I mentioned in the product meeting. ISTM the right thing for us to do here is take one or two of the driving use-cases and capture them as a story in aha, ensuring they're scheduled appropriately for the dependant teams.

I think the smallest-scoped stories in this vein are:

• The payments app wants to be able to look up the email address associated with an FxA uid
• The journeybuilder integration wants to query the set of devices connected to a user's account

Both of these without havin the user present to grant explicit permission. And IIUC both want to ship sometime this quarter.

@ametaireau mentions some slightly more complex ones in #125 (comment), but I think if we focus on hitting these two first, most of the details of other stories will fall out as a side-effect.

[rfk]

Closing this in favour of the feature card in mozilla/fxa#53