I have a requirement where a third-party app would like to authorize with our application. And while authorizing, they would like to send us a dynamic identifier in the access token which we would later use in each subsequent request.
They would like to set a custom scope with this dynamic identifier which we would read in our app. But, as far as I know, scopes can’t be dynamic, they need to be predefined in Auth0 dashboard (please correct me if I’m wrong). And scopes can’t be modified using actions, at least for now. Also, I’m pretty sure scopes are not meant for this kind of operation. They are a list of permissions that the client would use to request some protected resource from the resource server, so I want to avoid using scopes for this.
Another option is to use actions to set a custom claim, but the problem is that we would need to get that identifier from somewhere. We could query their API, but they would need to agree to build such an endpoint and we want to avoid that. Also, I’m not even sure if that’s doable on their side.
Another option that I’m considering right now is using actions to redirect a user to an external page and set that identifier there.
What would be the best approach for this? Should I continue with redirects or is there a better solution?
Yes, this is possible as well. When you use Redirect Actions, you will need to pass the dynamic identifier back to the authentication transaction to set the identifier in the Access/ID token.
May I ask if it is possible for you to set this dynamic identifier to the user’s metadata preemptively and then setting it as a custom claim when they log in?
No, it wouldn’t be possible to set the identifier preemptively because each time they log in on their side we need to set an identifier, and it may be different each time. Unless there is a way to do that before logging in (they are using Authorization Code Flow)? I know we can set it in the user management, but again it can change over time.
I already started experimenting with the third option, and I think this should work for us.
Also, I was reading the articles you sent me and I saw that redirect actions won’t work with the refresh token exchange. That is fine, we want to execute the redirection only when they log in initially, but then each time they exchange the refresh token we need to set that same identifier in the access token. So we would need to have two flows:
On login, redirect the user to the external page and set the identifier in the user metadata, which will be later set in token as a custom claim
When exchanging refresh token, same identifier from the metadata would need to be set as a claim in the token