Add access to refresh_token in Microsoft.Identity.Client.AuthenticationResult
See original GitHub issueIs your feature request related to a problem? Please describe. I need to use IPublicClientApplication.AcquireTokenWithDeviceCode(…) to handle authentication on some UI limited devices. These devices are running legacy code which requires both the access_token and the refresh_token. I can get the AuthenticationResult.AccessToken but there is no AuthenticationResult.RefreshToken. Using fiddler I can see the response from the server returns both an access_token and a refresh_token but for some reason the refresh token is not exposed in the result and I don’t see an easy way to get to it. I need to pass both of these tokens off to the legacy code so the system can work as it always has.
Describe the solution you’d like The easiest solution I’d like to see is to add a RefreshToken property to AuthenticationResult. Then its a matter of just handing the AuthenticationResult.AccessToken and AuthenticationResult.RefreshToken off to the legacy code and I’m done.
Or if there is a way to get at the refresh_token and someone can show me how to do it that would be appreciated as well.
IPublicClientApplication app = PublicClientApplicationBuilder
.Create(AppSettings.ClientId)
.WithTenantId(AppSettings.TenantId)
.Build();
DeviceCodeFlow oauth = new DeviceCodeFlow(app);
AuthenticationResult result = await oauth.AcquireTokenAsync(new[] { "...scopes..." }, deviceCodeCallback =>
{
// Prints message instructing user to go to https://microsoft.com/devicelogin and enter device code
Console.WriteLine(deviceCodeCallback.Message);
return Task.FromResult(0);
});
CallLegacyCodeWithTokens(result.Account.Username, result.AccessToken, result.RefreshToken);
Issue Analytics
- State:
- Created 4 years ago
- Comments:39 (9 by maintainers)
Top GitHub Comments
The easiest solution I could find to get around this problem is to create my own refresh token DelegateHandler and inject that into the HttpClient pipeline and execute a lambda when the refresh token comes back in a response. Now I’m able to pass the refresh token to the OneDriveClient and keep the legacy code as is. I still feel I should not have to do this and the refresh token should be part of the AuthenticationResult.
@MatLeger MSAL.NET (and MSALs in general) don’t expose the refresh tokens as they handle refreshing tokens automatically when you call AcquireTokenSilent. Refreshs may become obsolete when you use them, and therefore the code using them could easily break.
Can we understand a bit better what your legacy code with Token does? and why it needs the refresh tokens? would passing an IPublicClientApplication to get a token using app.AcquireTokenSilent() be good as well?