Hello,
I was testing out the refresh token implementation recently and ran into an issue. We have a rule that reaches out to an external service to grab the user's scopes based on what tenant they're logging into. We set this tenant_id on creation of the auth0 client. This works fine on a authorization_code flow, however the token refresh request doesn't include any custom query parameters added to the client and thus the rule breaks.
Is this a planned feature? If not, I could always pick apart the redirect_uri to figure out the tenant, but that's more complexity in the rule that I'd like to avoid.
Thanks @Hawxy, this actually looks like a bug as the additional params should be passed through. There was a change in 1.7 where getTokenSilently was refactored and these additional params were not taken into account.
I've raised this internally to fix - thanks for raising!
@stevehobbsdev hello! May you please share an estimated time of resolution/delivery for this bug if you're able to? Much appreciated.
@picosam It's in our backlog to hopefully address this week. I will of course report back here when it's done.
Hi all,
After having investigated this, we've de-escalated it from a bug as the SPA SDK has so far never sent custom options to the token endpoint. We accept custom options to getTokenSilently but they're for the purpose of the silent authorization call when _not_ using refresh tokens.
However, we see the use case and it will remain on our list to implement, but I don't have a timescale at the moment. We would of course be happy to work through a PR for this, should you wish to raise one.
Thanks @stevehobbsdev -- well that's certainly an issue for us. We have an application where the same user can access multiple companies with different access levels to each company data. We currently have a rule that injects a different role to the access token according to what company that user is trying to access. This is why when the user "switches the company they're viewing" on the React app, we try to get a new token for that user. However, we must pass along which company that user is trying to access so that the rule functions. Any advice on how we can currently do this?
We accept custom options to getTokenSilently but they're for the purpose of the silent authorization call when not using refresh tokens.
Sorry, yes that's what I was referring to. The iframe flow fires off the rule on the authorize call with the custom options required to call out and populate the token correctly, whilst the single oauth token request used in the refresh token flow fires off the rule but includes none of the custom options we require.
We have an application where the same user can access multiple companies with different access levels to each company data. We currently have a rule that injects a different role to the access token according to what company that user is trying to access.
We're in the same boat, with both the tenant and the product being sent to the rule via custom options.
Thanks for the extra detail on your use cases, on reflection I do agree this should be fixed. Let me start working on this today.
I think the only way right now until we fix it would be to not use a refresh token, as then the /authorize endpoint would be called with your custom parameters.
Most helpful comment
Sorry, yes that's what I was referring to. The iframe flow fires off the rule on the authorize call with the custom options required to call out and populate the token correctly, whilst the single oauth token request used in the refresh token flow fires off the rule but includes none of the custom options we require.
We're in the same boat, with both the tenant and the product being sent to the rule via custom options.