Why does node-oidc-provider refuse to issued a single token for both /userinfo endpoint and api(resource server) call ?
I don't see at anywhere in both oauth2 and open id connect specs that the authorization server should not issue an access token for both usage. This response also said that it's not impossible: Can we request OAuth 2 scopes in OIDC?
According to the doc of node-oidc-provider: https://github.com/panva/node-oidc-provider/tree/main/docs#featuresuserinfo
Enables the userinfo endpoint. Its use requires an opaque Access Token with at least openid scope that's without a Resource Server audience.
I'm missing something or what can i authenticate user and get directly access token with api call capability ?
My case: we have first party mobile app and our own authorization server and an api. So user login into the mobile app using "Connect with our server". With the situation described above, it's necessary to
This need 2 different interaction for user which can be not good.
This is updated informations according to @filip-skokan answer below.
According to your recommendation, correct me please if I'm wrong:
Solution 1: Triger the authorization request with resource paramater to get a token with the resource server scope. Use the idToken from that response to retrieve the userinfo without need to make a specific call to /userinfo.
Correct ?
Solution 2: Enable refreshToken issuing and trigger the authorization request with only userinfo scope (openid, email, etc) without resource scope. As Op server should return an access token and a refresh, I should use the refresh token to get a new access token with the resource scope.
Using the refresh token to get a resource scope access token may force end-user to grant this new scope to the client. Because, as said above we don't include in the authorization request the resource scope. This is a new interaction with the end-user. Right ?
Any explanation on this ?
I don't see at anywhere in both oauth2 and open id connect specs that the authorization server should not issue an access token for both usage
While that's true, there's also no language saying that's a good idea, and the fact is, it isn't.
The UserInfo endpoint is just another resource server and it is not possible to issue an access token for multiple resources (e.g. two APIs using the resource parameter). That's a choice I made to disallow resource servers taking their received access tokens and using the userinfo endpoint which is not a resource they are intended to consume.
This need 2 different interaction for user which can be not good.
You don't need 2 interactions. First of all, the mobile client can get everything that userinfo would return from the ID Token. Second, given the default behaviours, if the client doesn't use the corresponding resource parameter at the token endpoint a userinfo token will still be issued. My recommendation is to go the ID Token route, otherwise configure the environment to issue refresh tokens and have the client application get two access tokens from a single interaction that way.