This ropc policy configures a user journey to redeem a refresh token in JwtIssuer technical profile by setting RefreshTokenUserJourneyId. Can this approach be used for custom singin/signup policies as well? Or is this a specific feature for ropc? Is there any other documentation about RefreshTokenUserJourneyId, because this is the only place I could find where this is ever mentioned.
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
@HWouters Thanks for your feedback! We will investigate and update as appropriate.
@HWouters It can be used in any case.. All we are doing is specifying a user journey that should be executed when we are redeeming the refresh token to get new access token. Please check this

Ref: Define a technical profile for a JWT token issuer
Thank you for answering @SaurabhSharma-MSFT !
@HWouters We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.
A problem occurs when you are trying to get custom claims from claim providers during your journey. It actually does not update them, although the new claims are requested, for example with REST API provider.
Imagine that you’re getting a claim from your API. You will get a claim but it’s value will be the same as retrieved on generating first id_token. Refreshing it will not update that claim (but it will be requested - we see logs in the API).
I think we should reopen this ticket and discuss if this behaviour is by design.
@matjanos I have experienced the same issue. It seems the claims requested by a refresh token are never updated. Notice it's not only the case with claims requested by rest api, but also with build in claims like displayname. If you change the displayname in ad, it won't update the name claim in your idtoken. When you display the name of the signed in user in your application it will always show the old name, until the user actively do a signout and a new interactive signin.
The only useful thing I could do with this refresh user journey is checking if the refresh token is not revoked. Unfortunately if you don't do this, users can keep using their refresh token. Not being able to revoke refresh tokens, seem to me a security issue.
The thing I haven't tried is removing the user from ad. I wouldn't be surprised the refresh token is still giving back a new token with original old claims...
@SaurabhSharma-MSFT can this reopened the for the reasons given by @matjanos. Specifically, is this (not updating the claims returned in the token) behaviour by design?
@SaurabhSharma-MSFT, can we consider reopening this issue?
Most helpful comment
A problem occurs when you are trying to get custom claims from claim providers during your journey. It actually does not update them, although the new claims are requested, for example with REST API provider.
Imagine that you’re getting a claim from your API. You will get a claim but it’s value will be the same as retrieved on generating first id_token. Refreshing it will not update that claim (but it will be requested - we see logs in the API).
I think we should reopen this ticket and discuss if this behaviour is by design.