I know when we create tokens default token lifetime is 1 hour but I want to change that to 30 minutes.
I want to make tokens available for only 30 minutes to users. For any resource Get-AzAccessToken -ResourceTypeName MSGraph gives token available for 60 minutes.
With this token, users can call graph only within 1 hour. Now I want to make it to reduce to 30 minutes so that after that they have to request new token or the old token should not work.
How to do that? Anyone tried this before?
The default lifetime of an access token is variable. When issued, the default lifetime of an access token is assigned a random value ranging between 60-90 minutes (75 minutes on average).
Lifetime of an access token can be adjusted to control how often the client application expires the application session, and how often it requires the user to reauthenticate (either silently or interactively).
How to do that? Anyone tried this before?
To override the default access token lifetime variation, set a static default access token lifetime by using Configurable token lifetime (CTL).
A token lifetime policy is a type of policy object that contains token lifetime rules. This policy controls how long access, SAML, and ID tokens for this resource are considered valid. Token lifetime policies cannot be set for refresh and session tokens. If no policy is set, the system enforces the default lifetime value.
Refer to these documentations for more information:
On Creating Configurable token lifetime prolicy
Access token lifetime refer to this documentation.
Related
We are using Configurable token lifetimes in Azure Active Directory to change the max session age for multi-factor scenarios. While I've updated the policy with the command below, and confirmed that the access token lifetime changed from the default 60 minutes to 30 minutes, it did not change to 10 minutes as the policy indicates it should below. I've also confirmed it is the default org policy.
Set-AzureADPolicy -Id <OBJECT ID> -DisplayName "OrganizationDefaultPolicyUpdatedScenario" -Definition #('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"00:30:00","MaxAgeMultiFactor":"00:11:00","MaxAgeSessionMultiFactor":"00:10:00"}}')
I've checked the JWT token and confirmed exp is 30 minutes, so AccessTokenLifetime is implemented, but I'm using Outlook to test and confirmed MFA. The amr claim is "pwd,mfa".
Indirectly I think the MaxAgeMultiFactor timeout is working, but the session timeout is longer so it is hard to tell.
Why isn't MaxAgeSessionMultiFactor at 10 minutes (the minimum) working?
What am I doing wrong?
Complete policy:
class Policy
{
Id = 2a094bfe-d74e-4d55-906f-7cef8e54746b
OdataType =
AlternativeIdentifier =
Definition =
[
{
"TokenLifetimePolicy":
{
"Version":1,
"AccessTokenLifetime":"00:30:00",
"MaxAgeMultiFactor":"00:11:00",
"MaxAgeSessionMultiFactor":"00:10:00"
}
}
]
DisplayName = OrganizationDefaultPolicyUpdatedScenario
IsOrganizationDefault = True
KeyCredentials =
[
]
Type = TokenLifetimePolicy
}
Generally once access token is obtained, Azure AD will only check for the refresh token at the time of renewal. If the refresh token is also expired, Azure AD will then force the user for a fresh auth and check if MFA is required. If MFA is required, Azure AD will look to see if MFA cookie exists, MFA cookie is valid or not etc.
I see that you have only modified the access token lifetime and MFA lifetimes. So unless your MaxAgeSessionSingleFactor lifetime (Refresh Token) is less than MaxAgeSessionMultiFactor user will not be affected or prompted for MFA. Also single-factor authentication is considered less secure than multi-factor authentication, we recommend that you set MaxAgeSessionSingleFactor property to a value that is equal to or lesser than the Multi-Factor Refresh Token Max Age property(MaxAgeSessionMultiFactor).
With that being said, this feature is being deprecated as described in the article you are following. So we do not recommend using this feature in new environments.
"After hearing from customers during the preview, we're planning to replace this functionality with a new feature in Azure Active Directory Conditional Access. Once the new feature is complete, this functionality will eventually be deprecated after a notification period. If you use the Configurable Token Lifetime policy, be prepared to switch to the new Conditional Access feature once it's available." from the article.
I am using the Easy Auth feature of Azure App Service and I am trying to refresh a token with the Google provider.
I followed the Chris Gillum article and correctly called .auth/login/google with the access_type=offline parameter. Then I called .auth/refreshwhich return me a 200 OK with a new authenticationToken. However, when I check the claims of this ZUMO token by calling .auth/me, I can see that the Google token is in fact not refreshed despite the previous successful response. The exp claims (corresponding to Expiration Time) is the same as the previous token.
I tried several scenario : refresh the token immediately after receiving it, 10 minutes before the expiration time and after the expiration time (when the token is no longer valid) but in every scenario, Easy Auth return me a new ZUMO token but the Google token associated is always the same.
Is it normal for the .auth/refresh endpoint to always return the same token (same exp claims) with the Google provider ?
As Exchange authorization code for refresh and access tokens states about the refresh_token:
A token that you can use to obtain a new access token. Refresh tokens are valid until the user revokes access. Note that refresh tokens are always returned for installed applications.
And the response from Refreshing an access token only contains the access_token,expires_in (The remaining lifetime of the access token in seconds),token_type.
Is it normal for the .auth/refresh endpoint to always return the same token (same exp claims) with the Google provider ?
Using the Log stream under the MONITORING section of your app service, you could find the detailed log when calling .auth/refresh as follows:
Moreover, the exp claim when calling .auth/me represents the expire time for the authenticationToken instead of the refresh_token.
And you could leverage jwt.io to decode your authenticationToken and compare it with the exp user claim.
I have created access token using AcquireToken method (with default 1 hour expiration) and tried to login using below command
Add-AzureRmAccount -AccessToken "string" -AccountId "string"
It produces subscription details as expected by successful login.
After this i tried to update policy as below:
Set-AzureADPolicy -ObjectId <ObjectID FROM GET COMMAND> -DisplayName TenantDefaultPolicyUpdatedScenario -Definition #("{`"TokenLifetimePolicy`":{`"Version`":1,`"MaxAgeSingleFactor`":`"2.00:00:00`"}}")
But still token got expired in 1 hour.
Did i missed anything ?
what is the exact procedure and order of updating lifetime of token ?a
after setting policy how to ensure token life time ?
Thanks in advance.
According to this article, you should set AccessTokenLifetime property. Please try to use the following command.
Set-AzureADPolicy -Id <ObjectId FROM GET COMMAND> -DisplayName "OrganizationDefaultPolicyUpdatedScenario" -Definition #('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"1.00:00:00"}}')
The following is the snippet from the document.
Access Token Lifetime
String: AccessTokenLifetime
Affects: Access tokens, ID tokens
Summary: This policy controls how long access and ID tokens for this resource are considered valid. Reducing the Access Token Lifetime property mitigates the risk of an access token or ID token being used by a malicious actor for an extended period of time. (These tokens cannot be revoked.) The trade-off is that performance is adversely affected, because the tokens have to be replaced more often.
The MaxAgeSingleFactor property affects Refresh tokens.
Single-Factor Refresh Token Max Age
String: MaxAgeSingleFactor
Affects: Refresh tokens
Summary: This policy controls how long a user can use a refresh token to get a new access/refresh token pair after they last authenticated successfully by using only a single factor. After a user authenticates and receives a new refresh token, the user can use the refresh token flow for the specified period of time. (This is true as long as the current refresh token is not revoked, and it is not left unused for longer than the inactive time.) At that point, the user is forced to reauthenticate to receive a new refresh token.
Reducing the max age forces users to authenticate more often. Because single-factor authentication is considered less secure than multi-factor authentication, we recommend that you set this property to a value that is equal to or lesser than the Multi-Factor Refresh Token Max Age property.
Note: Access token without any expiry is a major security risk and it is not allowed in the Azure.
Default expiration of access token is 1 hour, minimum is 10 minutes, and the maximum is 1 day.
For more details, refer “Configurable token lifetimes in Azure Active Directory (Public Preview)”.
Can somebody explain how to implement sliding expiration using the new Owin WS-Federation plugin?
On the client side, at WS-Fedeartion configuration I see that there are some events like :
Notifications = new WsFederationAuthenticationNotifications
{
SecurityTokenReceived = ...,
AuthenticationFailed = ...,
RedirectToIdentityProvider = ...,
MessageReceived = ...,
SecurityTokenValidated = ....
},
But because the lack of documentation I can't really figure it out where an how?
At the moment my STS is issuing tokens with absolute expiration:
protected override Lifetime GetTokenLifetime(Lifetime requestLifetime)
{
// 5 Minutes for token lifetime
var lifetime = new Lifetime(DateTime.UtcNow, DateTime.UtcNow.AddMinutes(5));
return lifetime;
}
Any help is higly appreciated.
TL;DR: set WsFederationAuthenticationOptions.UseTokenLifetime to false, to re-enable sliding expiration.
In OWIN/Katana, the sliding expiration concept is limited to the cookies middleware and is enabled by default (you can turn it off by setting CookieAuthenticationOptions.SlidingExpiration to false: https://katanaproject.codeplex.com/SourceControl/latest#src/Microsoft.Owin.Security.Cookies/CookieAuthenticationOptions.cs).
When you use app.UseWsFederationAuthentication (or app.UseOpenIdConnectAuthentication), it actually relies on another middleware to persist the ClaimsIdentity when you complete the authentication flow. This "persistence delegation" can be configured through the SignInAsAuthenticationType or via app.SetDefaultSignInAsAuthenticationType.
Typically, this SignInAsAuthenticationType property corresponds to a cookie middleware: this way, sliding expiration is not managed at the WS-Federation middleware level, but by the cookies middleware, that will automatically renew the authentication cookie when sliding expiration conditions are met. In this scenario, the authentication token issued by your identity provider won't be renewed. For this to work, you need to set WsFederationAuthenticationOptions.UseTokenLifetime to false, because when you use the default value, sliding expiration is disabled and the cookie lifetime matches the token lifetime.
If you use WS-Fed for authentication purposes (i.e you just want to know who your users are), using sliding expiration is probably a good idea. But if you need to make some API calls on a remote server, your users may end up being authenticated for a long time, far after the expiration of their security token.
SharePoint uses SAML 1.1 as a protocol for federated authentication. A user will log in to a trusted identity provider and a SAML token is posted to the SharePoint site as a means of logging in to SharePoint.
I was surprised to find that the lifetime of the SAML token ties directly to the user's session. By default this seems to be 10 hours, which seems generous.
If I issue a SAML token to SharePoint what guard is there against replay attacks? It seems this token post is replayable for the lifetime of the user session. I would have expected the token lifetime to be long enough to authenticate. Is there something I am missing or is this a security hole?
The session lifetime in SharePoint will not be equals to the SAML token lifetime, but to the SAML Token ValidTo property (i.e. an absolute datetime), so the replay will work till that absolute time.
But there is more than that, SharePoint also relies on an internal property (defaults to 10 minutes) called LogonTokenCacheExpirationWindow. In my opinion, it brings more confusion than what value, but it's there and you have to understand that the validity of the session will depend on that
In pseudo code this is what happens inside SharePoint
SessionToken Lifetime = SAML Token Lifetime (by default)
if (SessionToken Lifetime - LogonTokenCacheExpirationWindow < DateTime.UtcNow)
Logout()
Here you have an illustration of that with LogonTokenExpirationWindow = 40 mins and SAML Token Lifetime 1hr.
The LogonTokenCacheExpirationWindow can be changed like this:
$sts = Get-SPSecurityTokenServiceConfig
$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 1)
$sts.Update()
The SAML token lifetime (in case you use ADFS) can be changed like this:
Set-ADFSRelyingPartyTrust -TargetName "My SP2010" -TokenLifetime 5
Finally, it is worth noting that SharePoint will issue persistent cookies by default. So when you close the browser and open it again, it will use that persistent cookie. You can change that by setting
$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.Update()
iisreset