Provide oauth-token-authenticated access to account profile data

[rfk]

With the upcoming work on Service Tokens in mozilla/fxa-oauth-server#336, we can no longer assume that the oauth server has access to profile information like email address. We need to provide a way for relying services to read this information directly from the auth-server, which is the canonical store for this data.

I propose that we extend the /account/status endpoint [1] for this purpose, as it's already used in vaguely this style to check on the existing of an account, and to read the locale of an account. It would accept profile:* scoped oauth tokens in addition to its existing session-token auth, and would return any of "email" and "locale" that the token allows. Requests with a sessionToken would return all available profile information:

> GET /account/status
> Authorization: Hawk some-session-token-thingy
.
< {
<   "exists": true,
<   "locale": "en-GB",
<   "email": "test@example.com"
< }

> GET /account/status
> Authorization: Bearer oauth-token-with-scope=profile
.
< {
<   "exists": true,
<   "locale": "en-GB",
<   "email": "test@example.com"
< }

> GET /account/status
> Authorization: Bearer oauth-token-with-scope=profile:email
.
< {
<   "exists": true,
<   "email": "test@example.com"
< }

@seanmonstar what do you think? As always, I'm very happy to take counter-propsals :-)

There's a WIP PR that implements essentially this logic at [2], but it'll need cleaning up and some additional scope-checking logic before we can land it.

[1] https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#get-v1accountstatus
[2] #915

[seanmonstar]

This seems fine for my needs, but I don't know if @dannycoates will feel like this is frankensteining the route 👹

[rfk]

We could add a new /account/profile that only takes oauth tokens if that seems cleaner overall; @dannycoates thoughts?

[dannycoates]

👍

In this narrow scope it looks fine. In the larger scope of "where do I find 'profile' data?" it looks odd. A reasonable person might think the profile-server. But we can save that for another day.

[rfk]

Yeah, I think the profile-server will more-or-less have to proxy this information out as part of its client-facing API. Which is weird.

[dannycoates]

Since there's some scope parsing I'd prefer /account/profile so we can leave /account/status unchanged.

[rfk]

I'd prefer /account/profile so we can leave /account/status unchanged.

On reflection, it may one day be reasonable for this API to grow write capabilities, to update things like the user's preferred locale. POST /account/profile seems sane, while POST /account/status would just be weird. So let's definitely go the former route.