1

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

  1. authenticate user (and get userinfo)
  2. Force user to authorize calling api (by requesting an access token for only usage on this api)

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:

  1. 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 ?

  2. 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 ?

Dahkenangnon
  • 66
  • 1
  • 9

1 Answers1

1

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.

  • Thank for your answer @filip-skokan For your choice of implementation focused seperating tokens from resources server even userinfo endpoint (as you consider it as a resource server), I agree 100% et like that choice. – Dahkenangnon Oct 15 '22 at 05:39
  • **I update my question above. can you consider the details please ? @filip-skokan** – Dahkenangnon Oct 15 '22 at 05:47
  • 1
    1) yes --- 2) no You will do an authorization request with resource parameter, then authorization code exchange without, fetch userinfo, then refresh token exchange with resource parameter, fetch resource. That's assuming you kept the default `features.resourceIndicators.useGrantedResource` configuration. –  Oct 15 '22 at 08:26
  • Thank for your useful response. I choose finaly the first option (retrieving user infos from idToken) you recommended as it just required one request to the auth server and fit my usecase. – Dahkenangnon Oct 15 '22 at 14:40
  • With **conformIdTokenClaims: true** (to make sure all requested scope are returned). – Dahkenangnon Oct 15 '22 at 14:40
  • I believe the value of that configuration flag is irrelevant when resource indicators are used. –  Oct 15 '22 at 14:41
  • Yes, of course but without this flag, the idToken contains only **sub** as said here: https://github.com/panva/node-oidc-provider/tree/main/docs#id-token-does-not-include-claims-other-than-sub – Dahkenangnon Oct 15 '22 at 14:43