Scopes in custom UserInfo claims

[johanneskvamme]

Great seeing OpenID Connect integrated into django-oauth-toolkit! 🎉
I am currently working on porting our systems from django-oidc-provider as many others probably are as well.

To keep the end-user experience as unchanged as possible, I would like both the /userinfo-endpoint and the ID-token to contain all approved scope-claims.
As such, I am following the instructions from the customizing-the-oidc-responses section.

First question:

The code snippet below does not send any arguments to super().get_userinfo_claims(), while my code complains that it wants the request, i.e super().get_userinfo_claims(request). Is it just missing in the docs or have I configured it wrongly?

class CustomOAuth2Validator(OAuth2Validator):

    def get_userinfo_claims(self, request):
        claims = super().get_userinfo_claims()
        claims["color_scheme"] = get_color_scheme(request.user)
        return claims

Second question:

When calling super().get_userinfo_claims(), my understanding is that it invokes get_additional_claims under the hood.
However, then passing the request at this point, no scope other than "openid" is present in the scope list. When generating the id_token, all scopes are present as they should, so I add different claims based on them. However, I seem to be unable to get the same claims for the /userinfo-endpoint. Am I doing something wrong, or is this a bug?

[n2ygk]

#956 fixes the documentation error for super().get_userinfo_claims().

Agree about the userinfo endpoint having only openid scope. I've seen this as well.

[tevansuk]

Agree about the userinfo endpoint having only openid scope. I've seen this as well.

Yes, we noticed this as well. This is oauthlib behaviour, it explicitly sets the scopes on the request to be just "openid" when generating userinfo claims - I think this is so it can skip through various "is this openid" checks that it has. It doesn't seem totally right to me.

You can get the original scopes however by looking at the access token / id token associated with the request:

scopes = request.access_token.scope.split()

I think a fix would need to be in oauthlib however.

[n2ygk]

I think a fix would need to be in oauthlib however.

In looking at oauthlib, it appears they "sanitize" the request and only have the Bearer token available, so I'm not sure it's more effective to grab the tokens in the DOT wrapper call to oauthlib.... What do you think @tevansuk?

[n2ygk]

closing this as stale