We have a post-login action to add custom claims to access tokens depending on the requested scopes - this works fine. We’re using it with auth0-angular, which automatically attempts refreshes the access token when necessary. This triggers our action, as expected. But as noted elsewhere (1, 2) the originally requested scopes are not available at this point (contrary to 3). So, unlike when logging in, we don’t know which claims to add when the token is refreshed.
Does anyone have an effective workaround for this? The auth0-angular FAQ suggests that it’s possible to manually refresh tokens. I guess we could do this and pass the scopes from the existing access token, but it isn’t ideal. Any ideas much appreciated!
How are you checking for requested scopes initially? As far as I can tell in some quick testing event.transaction.requested_scopes returns the same scopes in my initial login and successful silent auth (refresh token exchange).
Many thanks for the pointer. We’re currently checking scope and audience from event.request.query. I’ll have a look at getting scopes from event.transaction.requested_scopes and report back. Maybe we should also be using event.resource_server.identifier for audience.
Hi, thanks again for the suggestion. In our post-login Action we replaced event.request.query.scope with event.transaction.requested_scopes. Unfortunately this hasn’t resolved the issue: it works fine for initial login but the value is still undefined for refresh token exchange. It sounds like it worked for you so perhaps this is a configuration issue - if you have any further suggestions for debugging then they would be gratefully received.
Hey there @mwoodbri thanks for following up - My bad, I just tested again (and did some more research internally) and found that requested_scopes will return undefined which is expected behavior - Long story short, this is expected behavior because there technically are no requested scopes on the refresh token exchange. That being said, we are working to expose a event.refreshToken object which will contain this info. I am unfortunately unable to provide an ETA at this moment.
A potential workaround is to call this endpoint of the Management API, which will return the refresh tokens scope and be the same information contained in the eventual event.refreshToken object. To call this endpoint, you will need to configure your action to use the node management client. The following should be helpful:
Thanks - that sounds really promising. Do you know which plan is necessary to use the refresh-tokens endpoint? We have Developer but are seeing the following: