Is this correct way to specify scopes for password grant?

[linuxd3v]

Im doing password grant and a little stumped on how to specify scopes.
Looking at OpenIDConnectProvider code looks like scopes are specified in provider options.
I've tried that but this resulted in id_token not being returned.

After digging more I found that this worked for me - specifying when I call to get access token:

            $token = $oidcClient->getAccessToken('password', [
                'username' => $ue,
                'password' => $p,
                'scope'    => 'openid email username is_first_login',
            ]);

Which one is correct though? and why would I specify scopes in provider options then?

[steverhoades]

Off the top of my head I think the correct call would look something like...

    $token = $oidcClient->getAccessToken('password', [
                'username' => $ue,
                'password' => $p,
                'scopes'    => 'openid email username is_first_login',
            ]);

Notice scopes instead of scope.

[steverhoades]

Ah, disregard my last response. Jumped to a conclusion too quickly.

According to this:
https://github.com/thephpleague/oauth2-client/blob/master/src/Provider/AbstractProvider.php#L305

You must provide all the scopes you wish to receive within an access token request if you passing the scope option to the getAccessToken method. If you defined defaults than you should not need to provide the scope option with the getAccessToken call.

Have you tried that?

[linuxd3v]

Thanks,
I've initially tried adding scopes to the provider config instead, like this::

                    $provider = new \OpenIDConnectClient\OpenIDConnectProvider([
                            'clientId'                => 'myapp',
                            'clientSecret'            => 'something',

                            // Your server
                            'redirectUri'             => null,
                            'urlAuthorize'            => "$ssoHost/authorize",
                            'urlAccessToken'          => "$ssoHost/token",
                            'urlResourceOwnerDetails' => null,

                            'scopes' => ['openid', 'email', 'username', is_first_login],

                            // SSO Specific
                            'idTokenIssuer'           => $idTokenIssuer,
                            'publicKey'               => $publicKey,
                        ],
                        [
                            'signer' => $signer
                        ]
                    );

^which resulted in access token being returned without id token. not sure why - maybe because this is a password grant something fell through.

[steverhoades]

Does the OAuth2 server receive the openid scope when only using provider options?

Have you tried:

 $provider = new \OpenIDConnectClient\OpenIDConnectProvider([
        'clientId'                => 'myapp',
        'clientSecret'            => 'something',

        // Your server
        'redirectUri'             => null,
        'urlAuthorize'            => "$ssoHost/authorize",
        'urlAccessToken'          => "$ssoHost/token",
        'urlResourceOwnerDetails' => null,

        'scopes' => ['openid', 'email', 'username', 'is_first_login'],

        // SSO Specific
        'idTokenIssuer'           => $idTokenIssuer,
        'publicKey'               => $publicKey,
    ],
    [
        'signer' => $signer
    ]
);

 $token = $provider->getAccessToken('password', [
    'username' => $ue,
    'password' => $p
]);

The OpenIDConnectProvider "should" automatically add the openid scope if it's missing in the options. I'll try and get some time within the next few days to put together a test case for this.

[linuxd3v]

Example you posted above is exactly what I've tried :)
can't really test if oauth server receives openid scope (logging is out of my reach) - but I suspect it doesnt, as access token and refresh token get returned ok, just no id token.

[steverhoades]

No problem. I'll see if I can find the time to investigate this issue further.