Support email scope in authentication flow

[VJalili]

When I set scopes in my authentication request to ['openid', 'user'], I get an ID token whose context decodes as:

  "context": {
    "user": {
      "phone_number": null,
      "display_name": null,
      "name": "[email protected]",
      "is_admin": false,
      "policies": [],
      "email": null,
      "projects": {}
    }
  },

where name filed contains the email address, and the email field is null.

I changed the scope to ['openid', 'user', 'email'], but then I get the Unauthorized exception:

fence/fence/auth.py

Lines 98 to 104 in 31744be

	def check_scope_and_call(*args, **kwargs):
	if "_all" in flask.g.scopes or scope in flask.g.scopes:
	return f(*args, **kwargs)
	else:
	raise Unauthorized(
	"Requested scope {} can't access this endpoint".format(scope)
	)

because email is not a currently supported scope:

fence/fence/jwt/token.py

Lines 50 to 56 in 8337488

	CLIENT_ALLOWED_SCOPES = [
	"openid",
	"user",
	"data",
	"google_credentials",
	"google_service_account",
	]

I was wondering if can add a support for the email scope so a future context would decode as:

  "context": {
    "user": {
      "phone_number": null,
      "display_name": null,
      "name": "xyz",
      "is_admin": false,
      "policies": [],
      "email": "[email protected]",
      "projects": {}
    }
  },

[Avantol13]

Hey @VJalili ! thanks for the input, we actually don't support email as a separate field, we bundle all the user info into the context field and provide that under the user scope. The fact that you're not seeing an email in the email field has to do with how we create users for different identity providers. I'm assuming you have Google configured as the IDP, and when we create users from Google profiles, we use their email as their username. It's definitely a valid suggestion for us to also put that in the email field for Google as well, I will create a ticket on our end to support this

[Avantol13]

we could additionally support the email field as the OIDC spec defines, but then the email field would end up outside the context block, per the spec. Furher conformance to the optional features in OIDC are something we are continuing to pursue as well