userTokenManager.GetAccessTokenAsync with new scope

[michiproep]

Hi, I've got a short question on userTokenManager.GetAccessTokenAsync
If my initial login request has let's say these scopes: openid, email, offline_access, someScope
what is the expected result if I call

await userTokenManager.GetAccessTokenAsync(User,                     
  parameters: new UserTokenRequestParameters() { Scope = Scope.Parse("someOtherScope") });

or using

.AddUserAccessTokenHttpClient("userBackend", configureClient: client =>
{
    client.BaseAddress = new Uri("https://localhost:7048/api/");
}, parameters: new UserTokenRequestParameters() { Scope = Scope.Parse("someOtherScope") }
)

?
Should it throw an exception or would it use the refresh token to get a new access token for the requested scope?

I'm asking because it seems like as long as the initial access token is valid, there is no extra check or request done to fetch a new token which would match that scope.

[wcabus]

The default behavior is indeed using a cache to return the existing token if there still is a valid one. You can set ForceRenewal = true on the UserTokenRequestParameters passed in to get a new token.

That said, you won't be able to request an access token using scopes that weren't present in the initial request: the refresh token is bound to the scopes and resources that were initially requested. Put differently: you can only downscope access tokens when requesting a new one (when ForceRenewal = true or when the token is eventually renewed) using this method, depending on the identity provider (including IdentityServer).

[michiproep]

Hi @wcabus,
thanks for getting back to this. I have to admit I still have some problems to understand this - might be lack of knowledge, though.
In the initial login request I can only request a scopes which point to a single audience.
That said, I would not be possible to get an access token for resourceB using the refresh token but instead needing a redirect/roundtrip to the IdP with the new scopes?
Also, do all IdPs write all requested scopes into the tokens or how does the libaray know which scope was initially requested?

[wcabus]

In the initial login request, you're able to request as many scopes as you need, for different audiences as well, as long as the client application is allowed to request those scopes.

Applications, however, typically limit the number of scopes to the minimum required because of the grant / permission involved. Whenever a user performs an authorization flow for a client, the authorization server checks if the user has granted permission to the client. If the user then suddenly requires additional access, the IdP may need to show an additional consent screen like so:

[michiproep]

Hi @wcabus ,
thanks for that detailed explaination.
But there is still one last issue I don't understand: If I request "as many scopes as I need", how does the initial access token look like?
Does it have multiple audiences then and is audience overloading an issue?

But back to this library. Let's say, may initial access token has multiple audiences but my downstream apis don't accept tokens with multiple audiences, I probably need acquire the tokens with
parameters: new UserTokenRequestParameters() { Scope = Scope.Parse("someResourceScope"), ForceTokenRenewal = new ForceTokenRenewal() { Value = true } }

[bhazen]

If in the initial request, you request as many scopes as you need and those scopes are tied to multiple audiences, you'll end up with the cross product of those scopes and the audiences. If those scopes were tied to multiple audiences, the initial access token would have multiple audiences unless the request for the token included the resource parameter (more on that later). Whether or not multiple audiences in the token is an issue is dependent on if the resources to which you'll send that token will accept a token with multiple audiences. Per your comment, it sounds like in your specific case that would be a problem as you mentioned your downstream APIs do not accept a token with multiple audiences.

It sounds like Resource Isolation may be what you want for your case. In short, you would make the initial request with all the scopes you'll need. Then, when redeeming the code for a token, you can indicate the specific resource for which you need the access token and receive the access token for that resource and a refresh token. When you need to call another API, you can use the refresh token to obtain a new access token which is for that API.

[wcabus]

To acquire a token, you indeed need to use a custom UserTokenRequestParameters value. The signature has changed quite a bit between v3 and v4:

V3

parameters: new UserTokenRequestParameters()
{
    ForceRenewal = true,
    Scope = "api1 email",
    Resource = "urn:resource1" // If you would use resource isolation
}

V4

parameters: new UserTokenRequestParameters()
{
    ForceTokenRenewal = new ForceTokenRenewal(true),
    Scope = Scope.Parse("api1 email"),
    Resource = Resource.Parse("urn:resource1") // If you would use resource isolation
}