Open vladikoff opened 5 years ago
PR 3000, wooo
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
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:
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)
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.
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.
This repo has been deprecated and migrated to https://github.com/mozill/fxa. Please open this PR against that repo.
Fixes https://github.com/mozilla/fxa-auth-server/pull/2985/files#r268891903