Understanding Scopes and UserInfo Scopes
Scopes and userinfo_scopes both appear to do the same thing. Respectively, they both are sent to the Identity Provider in the same way. This article explains why it is necessary to have both available on an OpenID Connect-based connection.
- OpenID Connect (OIDC) Connection
- Userinfo_scope & Scopes
OpenID Connect-based connections have a designated field for scopes that are sent to the Identity Provider. There is another option within the User Mapping section, where it is also possible to specify userinfo_scopes. The naming of this property can cause some confusion, as it suggests the Identity Provider's userinfo endpoint is queried, but that is not the case. Any userinfo_scopes specified will be sent to the Identity Provider's authorize endpoint.
Userinfo_scope, when specified, takes precedence over the Scopes property within the OpenID Connect-based connections. The mentioned scopes are then sent to the Identity Provider's authorization endpoint.
Userinfo_scope is there primarily for backward compatibility purposes, so in most cases, this property will not be used, and the Scopes property should be used instead for clarity of scopes being sent to the Identity Provider.
To request user attributes from the Identity Provider's userinfo endpoint, the following mapping should be used, for example:
"given_name": "${context.userinfo.given_name}",
"family_name": "${context.userinfo.family_name}"
