I am working with the Identity Server 4 sample code. In particular, for the client I am using the sample MVC Client with the Hybrid flow: https://github.com/IdentityServer/IdentityServer4/tree/master/samples/Clients/src/MvcHybrid
And for the server I am using Identity Server with in-memory clients (no Entity Framework, and no ASP.Net Identity): https://github.com/IdentityServer/IdentityServer4/tree/master/samples/Quickstarts
Both client and server have pretty much vanilla, out-of-the-box configuration.
I am trying to understand how refresh tokens expire and how a native app can pro-actively determine the expiration time (before it gets rejected by an API). My understanding is that the default expiration for refresh tokens is long:
http://docs.identityserver.io/en/latest/topics/refresh_tokens.html:
Maximum lifetime of a refresh token in seconds. Defaults to 2592000 seconds / 30 days
However, when the sample code requests a refresh token, I do not get the expected expiration time. Here is the sample code:
var disco = await _discoveryCache.GetAsync();
if (disco.IsError) throw new Exception(disco.Error);
var rt = await HttpContext.GetTokenAsync("refresh_token");
var tokenClient = _httpClientFactory.CreateClient();
var tokenResult = await tokenClient.RequestRefreshTokenAsync(new RefreshTokenRequest
{
Address = disco.TokenEndpoint,
ClientId = "mvc.hybrid",
ClientSecret = "secret",
RefreshToken = rt
});
tokenResult.ExpiresIn is 3600 seconds, which is actually the expiration of an access token. I was expecting that to be 2592000 seconds. So question #1 is: Why is this the case?
But more importantly, I know that the expiration for the refresh token is in fact the default 30 days when I use SQL Server as the data store. There is a table PersistedGrants that contains the refresh tokens, and the expiration is clearly 30 days from the issue date. So question #2 is: How can an app programmatically determine the expiration date of the refresh token it received?
I've tried to parse the RefreshToken itself, but it is not really a full JWT, so this throws an error:
var jwt = new JwtSecurityTokenHandler().ReadJwtToken(accessTokenResponse.RefreshToken);
var diff = jwt.ValidTo - jwt.ValidFrom;
I've also searched through the IdentityServer4 unit / integration tests and cannot find an example of introspecting a refresh token.
Presumably that information either needs to be somewhere in the initial token response, or there needs to be an endpoint built into Identity Server. But I can't find either of these things.
Ok, so the answer is that there is no data in the access_token response that indicates the expiration time of the refresh_token. Additionally, there is no endpoint that can be used to check the expiration.
The OAuth spec does not say anything about this, so I did not want to alter the access_token response. I wound up making my own endpoint that returns the expiration time if needed. Here is my controller action, if anyone needs a starting point:
private readonly IRefreshTokenStore _refreshTokenStore; // inject this into your controller
...
[Route("[controller]/GetRefreshTokenExpiration")]
[Authorize(...YOUR SCOPE...)]
public async Task<IActionResult> GetRefreshTokenExpiration(string refreshTokenKey)
{
var refreshToken = await this._refreshTokenStore.GetRefreshTokenAsync(refreshTokenKey);
if (refreshToken == null)
{
return NotFound(new { message = "Refresh token not found" });
}
return Ok(new {
message = "Refresh token found",
lifetime_seconds = refreshToken.Lifetime
});
}
When one calls ../token
We get access_token, expires_in, refresh_expires_in, refresh_token and other stuff
Decode access_token to get ValidTo substract expires_in from ValidTo and then add refresh_expires_in to ValidTo and that should give you the expiry date of the refresh_token.
Related
I'm using .NET Core and IdentityServer4 for creating access-tokens. Those access tokens also include a refresh-token, which can be used to request new access-tokens. Since some users reported, that they get logged out too early I made a test in my local environment. I set the access-token-lifetime to 10 seconds, and the refresh-token lifetime to 30 seconds. The expected behaviour is, that you keep being logged in as long as you request a new token below 30 seconds. I then sent a request every few seconds. Every 10 seconds a new access-token is requested by the refresh-token. For this I use the Extension method "RequestRefreshTokenAsync". But this only works at max. 3 times:
04.12.2020 15:09:02 Using refresh token iCmtHJa5jllqTkwUexI9ZMLGN0RQhqvXljun6AgR31M.
04.12.2020 15:09:02 Success, new refresh token T0R8BWfNwkBzBh_yDKzhqerzgRgxY9OZ3jWLG951-hc.
04.12.2020 15:09:13 Using refresh token T0R8BWfNwkBzBh_yDKzhqerzgRgxY9OZ3jWLG951-hc.
04.12.2020 15:09:13 Success, new refresh token W29SlwHP318d4NFaqRS5ZTJAUG-ugYMBQrV6-g6v1rk.
04.12.2020 15:09:23 Using refresh token W29SlwHP318d4NFaqRS5ZTJAUG-ugYMBQrV6-g6v1rk.
04.12.2020 15:09:23 Error: invalid_grant
After I discovered this I also looked at the persistedgrants table of IdentityServer and it seems that for every refreshed access-token the same CreationTime and Expiration date is stored:
ocDMiwVpOJrcWh5LmEPgzDnn15TED5FpxSEpXsXDMzY= 2020-12-04 15:08:51.000000 2020-12-04 15:09:21.000000
i+NjVCnMUoobpnaINoLrCGcQrWHloIaAHC4NHWwGyK4= 2020-12-04 15:08:51.000000 2020-12-04 15:09:21.000000
d9HjtUszofxOEcnV7w95dhn54rl8QI2IRq8UMZlKr1Y= 2020-12-04 15:08:51.000000 2020-12-04 15:09:21.000000
What I would expect is, that when I request a new access-token, also the obviously new refresh-token gets a new expiration-date.
Does anybody know if I'm missing a specific setting or how to solve this issue?
What I have done to solve this is set your refresh token to have a sliding expiration. If you request a new access token before the sliding expiration then the refresh token expiration will be extended. This should be configurable in your identity server client settings. Check the docs here: http://docs.identityserver.io/en/release/topics/refresh_tokens.html
I'm using OAuth in .Net-Core 2.1 to Login to Coinbase, I've configured my authenticaton like so:
services.AddAuthentication(COOKIE_AUTH)
.AddCookie(options => options.ExpireTimeSpan = TimeSpan.FromMinutes(60))
.AddCoinbase(options => {
options.SendLimitAmount = 1;
options.SendLimitCurrency = "USD";
options.SendLimitPeriod = SendLimitPeriod.day;
options.ClientId = Configuration["Coinbase:ClientId"];
options.ClientSecret = Configuration["Coinbase:ClientSecret"];
COINBASE_SCOPES.ForEach(scope => options.Scope.Add(scope));
options.SaveTokens = true;
options.ClaimActions.MapJsonKey("urn:coinbase:avatar", "avatar_url");
});
Using Postman I see that I'm getting an access token and a refresh token. My token expires within two hours and never refreshes.
I know I can manually refresh the token, but I would expected this to be build into .net some where
Is there a way to refresh my token built into .net?
This doesn’t make sense since the client is responsible for sending a valid token in order to expect the request to be authorized. When clients typically send tokens , they typically do so in a header. That header only contains a single access token, not a refresh token. Instead the refresh token is persisted at the client and used to get an access token that IS valid. Then it can make a different request and expect a different outcome. The flow is important.
We have a OAuth API which provides expiring tokens to authenticate REST APIs in our application.
What I am trying to achieve
While application is running on server when first request comes through, get the expiring token, expiry date from OAuth API and store in the application somewhere and use that token until that expiry date and request for another token after that.This Token should be used Globally across the application until it expires.
What I have Done
Setup a Method which will get token from Oauth API and writing it to web.config file as App settings with the expiry date. whenever a request comes through to hit the REST API it will check if the token is available and not expired from web.config and return the Token. if the Token is not available or expired it will get a new token from OAuth API.
Web.Config
<appSettings>
<add key="Token" value="" />
<add key="ExpiryDate" value="" />
</appSettings>
CS file
public RESTAPI GetData()
{
string Token = GetToken();
//use this Token to Authenticate REST API
}
public string GetToken()
{
string Token = ConfigurationManager.AppSettings["Token"];
DateTime ExpiryDate = DateTime.parse(ConfigurationManager.AppSettings["ExpiryDate"]);
if(Token == "" || ExpiryDate<=DateTime.now)
{
RefreshToken();
}
return ConfigurationManager.AppSettings["Token"];
}
public void RefreshToken()
{
//Consider OauthObject as object returned from Oauth API with Token and expiry date
ConfigurationManager.AppSettings["Token"] = OauthObject.Token;
ConfigurationManager.AppSettings["ExpiryDate"] = OauthObject.ExpiryDate.toString();
}
I want one token to be distributed across the application for all users until it is expired. does it work this way if i want to do that? or any other suggestions please.
Note: ASP.Net web application written in C#.
For .Net Core you can store the authentication token in memory using the IMemoryCache interface, which you can inject easily to the consumer service using the build-in DI container.
That way you can store it within memory only for the expired time span that correlated with Expires_in, so afterwards it will be deleted automatically.
class RestConsumerService
{
private readonly IMemoryCache _memoryCache;
RestConsumerService(IMemoryCache memoryCache)
{
_memoryCache = memoryCache
}
string GetOAuthToken()
{
if (_memoryCache.TryGetValue<string>("MyTokenKey", out string access_token)) //You can store the T object as well.
{
return access_token;
}
//Do Api OAuth call
//...
OAuthRespone response = fetchAccessToken();
_memoryCache.Set("MyTokenKey", response.Access_token, new TimeSpan(0, 0, result.Expires_in));
return response.Access_token;
}
}
I'm not really sure why you want to store the access token in the first place. Why not just keep the token in memory while its valid?
From what you wrote, it looks like you want your application to act on its own behalf for any user. In that case, the OAuth2 client credentials flow is your best option.
Also, it may be better to just use the token until the API returns an HTTP 401 error and then renew the token and retry the API. If you store the expiration time, you have to account for clock-skew between machines. The issued token may be encrypted, in which case you cannot get the expiration time.
TL;DR
What is the difference between authenticating users with AuthenticationContext.AcquireTokenAsync() and MobileServiceClient.LoginAsync() ?
Can I use the token from the first method to authenticate a user in the second?
Long Version
I've been trying to authenticate users via a mobile device (iOS) for a mobile service in Azure with Xamarin Native (not Forms).
There are enough tutorials online to get you started but in the process, I got lost and confused...
What's working at the moment is the following; which has the user enter his credentials in another page and returns a JWT token which (if decoded here1) has the claims listed here2.
Moreover, this token is authorized in controllers with the [Authorize] attribute in requests with an Authorization header and a Bearer token.
Note: the following constants are taken from the registered applications in Active Directory (Native and Web App / API).
public const string Authority = #"https://login.windows.net/******.com";
public const string GraphResource = #"https://*******.azurewebsites.net/********";
public const string ClientId = "046b****-****-****-****-********0290";
public const string Resource = #"https://******.azurewebsites.net/.auth/login/done";
var authContext = new AuthenticationContext(Authority);
if (authContext.TokenCache.ReadItems().Any(c => c.Authority == Authority))
{
authContext = new AuthenticationContext(authContext.TokenCache.ReadItems().First().Authority);
}
var uri = new Uri(Resource);
var platformParams = new PlatformParameters(UIApplication.SharedApplication.KeyWindow.RootViewController);
AuthenticationResult authResult = await authContext.AcquireTokenAsync(GraphResource, ClientId, uri, platformParams);
Another working authentication flow I tried is the following; which does the same with the difference that it informs the user that the app requires permissions to access some resources.
If allowed, a JWT token (with less characters than the previous one) is returned with less payload data. This token though, won't pass the authorization attribute just like the previous one.
public const string AadResource = #"https://******.azurewebsites.net/.auth/aad";
var client = new MobileServiceClient(AadResource);
var rootView = UIApplication.SharedApplication.KeyWindow.RootViewController;
MobileServiceUser user = await client.LoginAsync(rootView, "aad");
Obviously, the return type is different, but, what is the main difference between these two authentication methods?
Additionally, another headache comes from trying to achieve this3 at the very end of the article. I already have the token from the first aforementioned method but when I try to follow the client flow with the token in client.LoginAsync() the following error is returned:
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
Link References:
https://jwt.io/
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-token-and-claims
https://adrianhall.github.io/develop-mobile-apps-with-csharp-and-azure/chapter2/enterprise/
https://www.reddit.com/r/xamarindevelopers/comments/6dw928/differences_between_acquiretokenasync/
Edit (30 May 2017)
The Why are they different? has been answered on this4 reddit post by the same person (pdx mobilist / saltydogdev) and the simple answer is claims.
Yes. You can insert a token into the MobileServicesClient and then use it had been authenticated directly. That's the beauty of bearer tokens.
Just set the MobileServiceClient CurrentUser:
MobileServiceclient Client;
...
Client.CurrentUser = new MobileServiceUser(username)
{ MobileServiceAuthenticationToken = authtoken};
Edit:
The reason they are different is because each library is requesting a different set of claims. The reason they still work is that the basic information for authenticating/validating the token is there. I'm not sure what are the specific required claims. At a minimum it would be the user id AND that the signature is valid. They are doing the same basic thing, MobileServiceClient just requests less claims.
I believe that the MobileServicesClient can authenticate against Azure AD, if you set up the mobile service correctly. So you should be able to just use the MobileServiceClient.
Here is the document that describes how this works: https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-how-to-configure-active-directory-authentication
I have a asp.net 4.5 webforms site that allows users to link their account to twitter and tweet directly from my site.
My app is registered with twitter and I am able to successfully authorise my app for the user's account and initially can tweet fine, but after a few hours the tweets stop working. I am using tweetsharp to handle the authorisation.
my code is:
TwitterClientInfo twitterClientInfo = new TwitterClientInfo();
twitterClientInfo.ConsumerKey = ConsumerKey;
twitterClientInfo.ConsumerSecret = ConsumerSecret;
var requestToken = new OAuthRequestToken { Token = oauthtoken };
TwitterService twitterService = new TwitterService(ConsumerKey, ConsumerSecret);
OAuthAccessToken accessToken = twitterService.GetAccessToken(requestToken, oauthverifier);
twitterService.AuthenticateWith(accessToken.Token, accessToken.TokenSecret);
TwitterUser user = twitterService.VerifyCredentials(new VerifyCredentialsOptions());
SendTweetOptions options = new SendTweetOptions();
options.Status = tweetText;
twitterService.SendTweet(options);
what i have noticed is that while the app is successfully tweeting, the accessToken.Token value that is being used to authenticate the user has a proper value (a long string of numbers and upper/lowercase characters) however when it stops tweeting the accessToken.Token value is just a single question mark "?".
Twitter says it doesn't expire tokens so i am at a loss to understand what is happening or how it can be resolved? if i went in to my twitter account and deauthorised my app and went through the authorisation again it would work fine for a few hours, but obviously that's not something i can ask my users to do.
can anyone suggest a resolution to this - either to stop the accessToken value becoming ? or to handle it and get a proper value if it does (without reauthorising the app)
Well, without beginning to understand the actual issue, I managed to fix it
Instead of retrieving the access token every time via:
var requestToken = new OAuthRequestToken { Token = oauthtoken };
OAuthAccessToken accessToken = twitterService.GetAccessToken(requestToken, oauthverifier);
twitterService.AuthenticateWith(accessToken.Token, accessToken.TokenSecret);
i only do that once and store accessToken.Token and accessToken.TokenSecret in the database and retrieve them when tweeting and supply them
twitterService.AuthenticateWith(accessTokenFromDB, accessokenSecretFromDB);
I have seen somewhere that Twitter doesn't expire tokens, so this should work. Certainly it's been working for me all weekend whereas the original code would stop working after a few hours.
Thought this might help some others who have the same issue.