Auth0-spa-js: Falls back to iframe when audience is used?

[qortex]

It seems, looking at here:
https://github.com/auth0/auth0-spa-js/blob/6cfa341bf7ef1f847d5a2c2a55d01c56b39dd2be/src/Auth0Client.ts#L566-L570

that specifying an audience to the Auth0Client object disables using refresh tokens. Is it expected behaviour? From what I can tell, this is not documented and came as a surprise to me.

Found that while making sure my app uses RT correctly. Turns out I was specifying an audience (the default one, I have only one). Stopping to specify the audience and putting a default audience in my tenant asked a new "approval" for the app, so I guess it changed the flow somehow.

Could someone from the team explain what is at stake here, and how to use RT for sure? It's hard to know if it's properly configured as of now. Or maybe you have a good way to check?

Thanks

[stevehobbsdev]

If you only have one audience and do not intend to change it, just specify it when you create the client. There's no need to specify it to getTokenSilently as well if the audience is the same.

However, I can see the logic here is flawed and should allow you to continue using that refresh token if the audience is not different to the one you specify at creation time, so this can be changed.

We have some work coming up that improves the way caching works internally which will fix this issue, but I don't have an ETA to share currently. Instead, please work around it by only specifying the audience at creation time, if you only have one audience to use.

I should also point out that if you're being asked for consent for this, you will always be asked for consent when running on localhost (the "skip consent for first-party apps" flag is ignore) but should work just fine when deployed.

[qortex]

Thanks for the reply.

That's already what I do: I don't use arguments to getTokenSilently and just have the audience field setup at client creation time.

But it can be seen here:
https://github.com/auth0/auth0-spa-js/blob/6cfa341bf7ef1f847d5a2c2a55d01c56b39dd2be/src/Auth0Client.ts#L539-L544

Even if you don't specify something in the arguments, it pulls it from the main options.

So the only way left is to not provide it at creation time, unless I missed something.

A quick fix would be to not pull it from the main config, but it would be a breaking change I guess.

My workaround is to not specify it at creation time now.

[mendhak]

@stevehobbsdev is there any workaround for when we do require multiple audiences?
We've just hit on this problem, we're using refresh tokens but specifying an audience with getTokenSilently makes use of iframe.

[qortex]

(@stevehobbsdev this issue should not be closed IMO, see my comment & this new one)

[stevehobbsdev]

@qortex The problem you're having is still not clear to me.

My workaround is to not specify it at creation time now.

What is it you're trying to work around?

If you have one audience, you want to specify it at creation time so that when the SDK goes through the OIDC dance, you get an access token and refresh token back for that audience.

If you specify an audience when you call getTokenSilently, we have to fall back to using the iframe because you cannot call the token endpoint with the refresh_token grant and an audience. The refresh token you have is already bound to an audience and can't be changed by using the token endpoint by itself, you would have to put the user back through an interactive flow if you can't rely on the iframe method. You can either do a full redirect flow or use something like getTokenUsingPopup.

this issue should not be closed IMO, see my comment & this new one

I'll happy reopen if we can't resolve this through conversation. But the new comment is a different scenario to yours.

[stevehobbsdev]

@mendhak The multiple scenario one is unfortunately unclear. Auth0 does not allow you to request access tokens for multiple audiences and this gets quite messy when you consider how to specify scopes for each audience, getting multiple refresh tokens back, etc.

If you cannot rely on the iframe method (because of blocked third-party cookies, for example) then you have a couple of tools: you can use multiple scopes, or request access tokens just-in-time using something like getTokenUsingPopup.

[qortex]

@qortex The problem you're having is still not clear to me.

Ah yes, I just realized I misread the code, sorry for the trouble :)