feat(token): return the uid from the /token endpoint

[vladikoff]

Fixes https://github.com/mozilla/fxa-auth-server/pull/2985/files#r268891903

[vladikoff]

PR 3000, wooo

Blocks #2985

[shane-tomlinson]

This makes me uncomfortable because we take care to only return an id_token if the grant contains the openid scope, which contains the same info in sub. With this change we are adding the uid whether requested or not and whether granted or not. While that is acceptable for requests coming from the auth-server, that falls outside of expected behavior for the general case.

Could we somehow restrict this behavior to auth-server originating calls? Or, the auth server adds the openid scope when calling the oauth-server's /token endpoint and then remove the id_token if the RP didn't actually request it?

[shane-tomlinson]

What if we call this sub like we do for an id token. At least it'd be consistent. But I see verify returns user. mmm...

[vladikoff]

another idea is to use the fxa-uid field

[shane-tomlinson]

Changing to "request changes" to figure out how to only return this parameter when expectations are met.

[vladikoff]

With this change we are adding the uid whether requested or not and whether granted or not. While that is acceptable for requests coming from the auth-server, that falls outside of expected behavior for the general case.

UID can be easily obtain by calling verify token

[rfk]

With this change we are adding the uid whether requested or not and whether granted or not.

AFAICT the /verify endpoint will unconditionally return the uid when you present it with a valid access token, regardless of what scopes have been granted to that token:

fxa-auth-server/fxa-oauth-server/lib/token.js

Line 55 in 9564168

user: token.userId.toString('hex'),

Which is why we figured it would be OK to return it here as well. But perhaps that's an oversight rather than a deliberate behaviour.

(Edit: lol, mid-air comment collision with vlad's response)

[rfk]

Could we somehow restrict this behavior to auth-server originating calls?

Another option would be to only return it when the scopes explicitly allow it, e.g. when requesting profile or openid scope. I expect this would suffice for the cases where the auth-server wants to know this value without a second db lookup.

[shane-tomlinson]

Another option would be to only return it when the scopes explicitly allow it, e.g. when requesting profile or openid scope. I expect this would suffice for the cases where the auth-server wants to know this value without a second db lookup.

It could be that we assumed all RPs would at least request profile, though that's not guaranteed. I'd prefer us to do some minimal checking on /verify too to prevent RPs from getting info not explicitly granted.

[shane-tomlinson]

This repo has been deprecated and migrated to https://github.com/mozill/fxa. Please open this PR against that repo.