We Keep Coding

Identity server 4 handling Expired or revoked refresh tokens

I am working with an Identity server 4 system. We are using the exact code from the MvcHybridAutomaticRefresh sample
The issue is with this code here. AutomaticTokenManagementCookieEvents.cs#L73
var response = await _service.RefreshTokenAsync(refreshToken.Value);
if (response.IsError)
{
_logger.LogWarning("Error refreshing token: {error}", response.Error);
return;
}
Currently if a refesh token was revoked by the admins, or the refresh token has expired ( we do not have sliding refresh tokens enabled) Then the application will crash. I would expect it to reroute the user to the login screen.
I am i missing something in this sample that it cant handle that?
I have also posted this as a question on the issue forum #3599
current attempt
is to add The following rather where it detects the error
await context.HttpContext.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
which i had hoped would log the user out. This just hangs and never goes anywhere. Its not even logging you out of the server.
Current Solution
The only thing i can find currently that remotely works is to add a catch in the api call. This is not ideal as in our actual application we have a lot of api calls this would mean making a lot of changes to our application. Isnt there a way to force a login directly from the middle wear itself?
[Authorize]
public async Task<IActionResult> CallApi()
{
try
{
var token = await HttpContext.GetTokenAsync("access_token");
var client = _httpClientFactory.CreateClient();
client.SetBearerToken(token);
var response = await client.GetStringAsync(Constants.SampleApi + "identity");
ViewBag.Json = JArray.Parse(response).ToString();
return View();
}
catch (Exception)
{
return new SignOutResult(new[] { "Cookies", "oidc" });
}
}

You can add just one row to force the middleware to perform the challenge again:
if (response.IsError)
{
_logger.LogWarning("Error refreshing token: {error}", response.Error);
context.RejectPrincipal();
return;
}

Persist sign-in Microsoft-Graph c# SDK

I'm using Microsoft Graph C#.NET SDK to access user's mail inbox. The problem is that when I do authentication the token that Microsoft sends me back is valid just for 1 hour or so and it expires so early. But it's so annoying for user to login every 1 hours just to see the outlook mail inbox. I need to make this login PERSISTENT.
Here is the code that I use:
public static async Task Run()
{
string secret = "MyDamnPrivateSecret";
PublicClientApplication clientApp = new PublicClientApplication(secret);
GraphServiceClient graphClient = new GraphServiceClient("https://graph.microsoft.com/v1.0", new DelegateAuthenticationProvider(async (requestMessage) =>
{
requestMessage.Headers.Authorization = new AuthenticationHeaderValue("bearer", await GetTokenAsync(clientApp));
}));
//Processing mailbox ...
}
private static async Task<string> GetTokenAsync(PublicClientApplication clientApp)
{
if (string.IsNullOrEmpty(Properties.Settings.Default.token) || string.IsNullOrWhiteSpace(Properties.Settings.Default.token))
{
//need to pass scope of activity to get token
string[] Scopes = { "User.Read", "Mail.ReadWrite" };
string token = null;
AuthenticationResult authResult = await clientApp.AcquireTokenAsync(Scopes);
token = authResult.AccessToken;
Properties.Settings.Default.token = token;
Properties.Settings.Default.Save();
return token;
}
else
{
return Properties.Settings.Default.token;
}
}
Is there any way to make expiration time last longer? Or make a refresh token or something to persist login?

You'll need to request the offline_access scope to get a refresh token. If you're using an older version of MSAL, you'll need to implement and pass a token cache in the PublicClientApplication constructor which I think that MSAL will use to automatically refresh the access token. I think the newer version handles the tokenCache for you.
From the docs, this is the recommended call pattern: first try to call AcquireTokenSilentAsync, and if it fails with a MsalUiRequiredException, call AcquireTokenAsync.
private static async Task<string> GetTokenAsync(PublicClientApplication clientApp)
{
AuthenticationResult result = null;
try
{
string[] scopes = { "User.Read", "Mail.ReadWrite", "offline_access" };
// Get the token from the cache.
result = await app.AcquireTokenSilentAsync(scopes, clientApp.Users.FirstOrDefault());
return result.AccessToken;
}
catch (MsalUiRequiredException ex)
{
// A MsalUiRequiredException happened on AcquireTokenSilentAsync.
// This indicates you need to call AcquireTokenAsync to acquire a token
System.Diagnostics.Debug.WriteLine($"MsalUiRequiredException: {ex.Message}");
try
{
// Dialog opens for user.
result = await app.AcquireTokenAsync(scopes);
return result.AccessToken;
}
catch (MsalException msalex)
{
ResultText.Text = $"Error Acquiring Token:{System.Environment.NewLine}{msalex}";
}
}
catch (Exception ex)
{
ResultText.Text = $"Error Acquiring Token Silently:{System.Environment.NewLine}{ex}";
return;
}
}
Here's a sample for reference. https://github.com/Azure-Samples/active-directory-dotnet-desktop-msgraph-v2

I will try to clarify the issues here:
MSAL .net is build for different platforms - .net desktop, .net core, UWP, xamarin android and xamarin iOS. On some of these platforms (UWP and xamarin) we persist the token cache for you. On the others, we expect you to persist the cache. The reason is that we cannot provide token serialization logic that works well for all scenarios (e.g. ASP.NET server farms), so we expect you to do it. We provide samples and guidance around it this. Details and some reference implementations on the MSAL wiki:
The sample code provided by #Michael is ok for MSAL v1. In MSAL v2 the things are a bit different and you can find the pattern of calling is also on the MSAL wiki:
We request and store the refresh token (RT). If the auth token (AT) is expired, we will request a new one based on the RT - this will happen without user interaction. This should all be transparent to you, i.e. it should just work :). Make sure that your token cache serialization works, i.e. you get an account when performing
// perform an interactive login first
// otherwise there will be no AT / RT in the store
var accounts = await app.GetAccountsAsync();
// there should be an account that you can use
Most of our samples show how to call the Graph. See all the samples by scenario here. For your use case I recommend you check out Calling the Graph from a WPF app
Also check out #Daniel Dobalian's answer for default expiration of AT and RT:
MSAL token expires after 1 hour

In your code, AcquireTokenAsync does always trigger login.
Instead, you need to implement a token cache and use AcquireTokenSilentAsync.
For more information, please review the following link:
Microsoft Graph SDK - Login

MSAL Error message AADSTS65005 when trying to get token for accessing custom api

I downloaded the example below to get an access token from MS Graph and it worked fine. Now I changed the code to get a token from a custom web API. On apps.dev.microsoft.com I registered a client application and an the API.
Client and server registration in AD
private static async Task<AuthenticationResult> GetToken()
{
const string clientId = "185adc28-7e72-4f07-a052-651755513825";
var clientApp = new PublicClientApplication(clientId);
AuthenticationResult result = null;
string[] scopes = new string[] { "api://f69953b0-2d7f-4523-a8df-01f216b55200/Test" };
try
{
result = await clientApp.AcquireTokenAsync(scopes, "", UIBehavior.SelectAccount, string.Empty);
}
catch (Exception x)
{
if (x.Message == "User canceled authentication")
{
}
return null;
}
return result;
}
When I run the code I login to AD via the dialog en get the following exception in the debugger:
Error: Invalid client Message = "AADSTS65005: The application
'CoreWebAPIAzureADClient' asked for scope 'offline_access' that
doesn't exist on the resource. Contact the app vendor.\r\nTrace ID:
56a4b5ad-8ca1-4c41-b961-c74d84911300\r\nCorrelation ID:
a4350378-b802-4364-8464-c6fdf105cbf1\r...
Error message
Help appreciated trying for days...

For anyone still striking this problem, please read this:
https://www.andrew-best.com/posts/please-sir-can-i-have-some-auth/
You'll feel better after this guy reflects all of your frustrations, except that he works it out...
If using adal.js, for your scope you need to use
const tokenRequest = {
scopes: ["https://management.azure.com/user_impersonation"]
};
I spent a week using
const tokenRequest = {
scopes: ["user_impersonation"]
};
.. since that is the format that the graph API scopes took

As of today, the V2 Endpoint does not support API access other than the Microsoft Graph. See the limitations of the V2 app model here.
Standalone Web APIs
You can use the v2.0 endpoint to build a Web API that is secured with
OAuth 2.0. However, that Web API can receive tokens only from an
application that has the same Application ID. You cannot access a Web
API from a client that has a different Application ID. The client
won't be able to request or obtain permissions to your Web API.
For the specific scenario that you are trying to accomplish, you need to use the V1 App Model (register apps on https://portal.azure.com).
In the very near future, V2 apps will be enabled to call other APIs other than Microsoft Graph, so your scenario will be supported, but that is just not the case today. You should keep an eye out on our documentation for this update.

In your (server) application registration in AAD, you need to specify your scopes in the oauth2Permissions element.
You may already have a user_impersonation scope set. Copy that as a baseline, give it a unique GUID and value, and then AAD will let your client request an access token with your new scope.

Persistent authentication across UWP app and Azure Mobile Service

Building on the example here I'm attempting to authenticate an MSA login on the client, and have it authenticate service-side as well. The difference with mine is I'm using the new WebAccount-related API's in Windows 10 instead of the now deprecated Live SDK.
So far I've got:
var provider = await WebAuthenticationCoreManager.FindAccountProviderAsync("https://login.microsoft.com", "consumers");
var request = new WebTokenRequest(provider, "service::wl.basic wl.emails::DELEGATION", "none");
var result = await WebAuthenticationCoreManager.RequestTokenAsync(request);
if (result.ResponseStatus == WebTokenRequestStatus.Success)
{
string token = result.ResponseData[0].Token;
//This calls my custom wrappers around the Live REST API v5 and runs successfully with this token
var acc = await LiveApi.GetLiveAccount(token);
var jtoken = new JObject
{
{"authenticationToken", token}
};
try
{
//Shouldn't this work? but raises a 401
await App.MobileService.LoginAsync(MobileServiceAuthenticationProvider.MicrosoftAccount, jtoken);
//Alternate method? Also raises a 401
//await App.MobileService.LoginWithMicrosoftAccountAsync(token);
}
}
As I mentioned in the comments, all I get are 401s.
As far as I can tell the application is configured correctly in Microsoft Account dev center:
I'm using the client ID and secret from the same app in the Azure portal.
JWT issuing is not restricted.
Redirect URL is of the format https://{appname}.azurewebsites.net/.auth/login/microsoftaccount/callback
Authentication works fine when I switch to use purely server-side authentication. i.e.
await App.MobileService.LoginAsync(MobileServiceAuthenticationProvider.MicrosoftAccount);
Any ideas? Am I missing something? Any help would be appreciated.
UPDATED:
The token I get back in the WebTokenRequestResult is 877 characters long and does not appear to be in the JWT format, with the dot (.) separators and I'm quite certain that this is the issue. The following error gets logged in service when the client calls the code above:
JWT validation failed: IDX10708: 'System.IdentityModel.Tokens.JwtSecurityTokenHandler' cannot read this string: 'EwCQAq1DBAAUGCCXc8wU/zFu9QnLdZXy+...Zz9TbuxCowNxsEPPOvXwE='.
Application: The string needs to be in compact JSON format, which is of the form: '<Base64UrlEncodedHeader>.<Base64UrlEndcodedPayload>.<OPTIONAL, Base64UrlEncodedSignature>'..
Application: 2015-12-07T17:47:09 PID[5740] Information Sending response: 401.71 Unauthorized
What format is the token currently in? Can it be transformed to a JWT?
Still no closer to a solution, so any help is appreciated.

Anyone feel free to correct me, but it looks like RequestTokenAsync gets you an access token which you can't use to login the backend. You need an authentication token for that, and as far as I can see RequestTokenAsync doesn't get you that.
There's some info here about the tokens.

If people end up here searching for a solution for App Service Mobile, the update to MobileService. Then there is now a solution
The code replicated here is:
async Task<string> GetDataAsync()
{
try
{
return await App.MobileService.InvokeApiAsync<string>("values");
}
catch (MobileServiceInvalidOperationException e)
{
if (e.Response.StatusCode != HttpStatusCode.Unauthorized)
{
throw;
}
}
// Calling /.auth/refresh will update the tokens in the token store
// and will also return a new mobile authentication token.
JObject refreshJson = (JObject)await App.MobileService.InvokeApiAsync(
"/.auth/refresh",
HttpMethod.Get,
null);
string newToken = refreshJson["authenticationToken"].Value<string>();
App.MobileService.CurrentUser.MobileServiceAuthenticationToken
= newToken;
return await App.MobileService.InvokeApiAsync<string>("values");
}
Hope it saves somebody time !

"Microsoft.Office365.Discovery.DiscoveryFailedException: Unauthorized" when creating a DiscoveryClient object

I've got an ASP.Net MVC 5 web application that is attempting to integrate with Office 365/Azure AD.
The application successfully allows Sign In/Out, as well as successfully delegates permission for Graph API calls and calls to a separate Web API of mine which auths against Azure AD. So, something is working.
However, when trying to create a DiscoveryClient object, I am getting the Unauthorised ErrorCode in a DiscoveryFailedException.
The offending method:
public static async Task<SharePointClient> CreateSharePointClientAsync(string capability)
{
var signInUserId = ClaimsPrincipal.Current.FindFirst(System.IdentityModel.Claims.ClaimTypes.NameIdentifier).Value;
var userObjectId = ClaimsPrincipal.Current.FindFirst("http://schemas.microsoft.com/identity/claims/objectidentifier").Value;
AuthenticationContext ctx = new AuthenticationContext(OfficeSettings.Authority, new NaiveSessionCache(signInUserId));
var credential = new ClientCredential(OfficeSettings.ClientId, OfficeSettings.ClientSecret);
var userIdent = new UserIdentifier(userObjectId, UserIdentifierType.UniqueId);
try
{
DiscoveryClient discoClient = new DiscoveryClient("https://api.office.com/discovery/v1.0/me/",
async () =>
{
var authResult = await ctx.AcquireTokenAsync("https://api.office.com/discovery/",
credential);
return authResult.AccessToken;
});
var capabilityResult = await discoClient.DiscoverCapabilityAsync(capability);
return new SharePointClient(capabilityResult.ServiceEndpointUri,
async () =>
{
var authResult = await ctx.AcquireTokenAsync(capabilityResult.ServiceResourceId,
credential);
return authResult.AccessToken;
});
}
catch (AdalException ex)
{
if (ex.ErrorCode == AdalError.FailedToAcquireTokenSilently)
{
ctx.TokenCache.Clear();
throw ex;
}
return null;
}
catch (Exception ex)
{
throw ex;
}
}
The error occurs at the call to ctx.AcquireTokenAsync in the lambda of the DiscoveryClient instantiation.
As above, the application can sign in users, so the ClientId/Secret must be correct and I also believe the permissions required for this are similar to what is required to use the Discovery Service.
I've also tried to skip the discovery step and just hard-code the ResourceId for the Sharepoint client to see if I can leave it like this for the time being; however, I'm also getting some permission errors here, too, despite the appropriate permissions being granted for the application in the AAD management page.
I'm at a complete loss; running the example application from O365-ASPNETMVC-Start works as you'd expect using the same credentials to sign in to Office 365.
To try and pinpoint the issue, the (what I believe to be the relevant) code is now practically identical to the (working) example, with still no luck.
If any other code would be useful in solving the issue, I'll happily share.
Any ideas would be hugely appreciated.

To start, I haven't tried to alter the O365-ASPNETMVC-Start sample to work with the unified API endpoint (Graph API). While I haven't tried what you're doing, I'd expect the discovery calls to not work when targeting the unified API. The discoveryClient was useful when you needed to discover the endpoint. Since there is only one endpoint, there is no need to discover it. I suggest you take a look at Office 365 unified API overview (preview) to get some more background.
I suggest you take a look at the
Office 365 Profile sample for Windows as it uses the unified endpoint. It uses the unified API client library that you'll want to use if targeting the unified endpoint.
Do note that the unified API is in preview. The APIs used by the O365-ASPNETMVC-Start sample are what is currently endorsed for production use.
Please tag your question with the [Office365] tag so that other interested people can see your question.
With regards,