You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been reading through documentation for a bit now and I am very confused on what flow to model for our use case. We need the admin user to grant the access with the crm.dynamics.com/user_impersonation scope, so we can perform API calls for organizations Dynamics Sales data. We cannot have a user re-authorize after they granted the initial token, the actions happening are dictated by events occurring in the CRM, initialized from our web app, or as a result of hitting our API. We need our server to be able to handle all refreshing from then on silently without user interactions.
I have seen MSAL is purposefully designed to hide the refresh token and the library will handle the refreshing of the access token itself. The documentation seems to state that there is always potential for the library to require the user to re-authorize if it cannot handle the refreshing assuming the cached access token is expired. This will not work for us. Given our use case what is the correct flow to use here? I would prefer to be in full control of the token refreshing.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I've been reading through documentation for a bit now and I am very confused on what flow to model for our use case. We need the admin user to grant the access with the
crm.dynamics.com/user_impersonation
scope, so we can perform API calls for organizations Dynamics Sales data. We cannot have a user re-authorize after they granted the initial token, the actions happening are dictated by events occurring in the CRM, initialized from our web app, or as a result of hitting our API. We need our server to be able to handle all refreshing from then on silently without user interactions.I have seen MSAL is purposefully designed to hide the refresh token and the library will handle the refreshing of the access token itself. The documentation seems to state that there is always potential for the library to require the user to re-authorize if it cannot handle the refreshing assuming the cached access token is expired. This will not work for us. Given our use case what is the correct flow to use here? I would prefer to be in full control of the token refreshing.
Beta Was this translation helpful? Give feedback.
All reactions