We are using Oauth2 with Azure. And by default server returns token with an hour interval for expiration. Is there any way change expiration interval?
It is now possible to configure the token lifetime. You can read more here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token-lifetimes.
Remark: This feature is in preview and will not go to production in this way. The following header is also placed on the documentation link I mentioned above.
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.
Original answer:
Currently there is no way to change the expiration interval. These are the current expiration times.
Access tokens last 1 hour
Refresh tokens last for 14 days, but
If you use a refresh token within those 14 days, you will receive a new one with a new validity window shifted forward of another 14 days. You can repeat this trick for up to 90 days of total validity, then you’ll have to reauthenticate
Refresh tokens can be invalidated at ANY time, for reasons independent from your app (e.g. user changes password). Hence you should NOT take a dependency on the above in your code – your logic should always assume that the refresh token can fail at any time
Refresh tokens issues for guest MSA accounts last only 12 hours
Source: http://www.cloudidentity.com/blog/2015/03/20/azure-ad-token-lifetime/ and also my own experiences.
You have to use power shell to perform 2 steps as below:
Create new policy. This policy sets timeout 2 hours
New-AzureADPolicy -Definition #('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"02:00:00","MaxAgeSessionSingleFactor":"02:00:00"}}') -DisplayName "MyWebPolicyScenario" -IsOrganizationDefault $false -Type "TokenLifetimePolicy"
Apply this policy to your website
Add-AzureADServicePrincipalPolicy -Id <ObjectId of the ServicePrincipal> -RefObjectId <ObjectId of the Policy>
Note:
In order to get ObjectId of the ServicePrincipal, run this command: Get-AzureADServicePrincipal
To get ObjectId of the Policy, run this command: Get-AzureADPolicy
For more detail you can refer to this document: https://learn.microsoft.com/en-us/azure/active-directory/active-directory-configurable-token-lifetimes
Assuming you're talking about Azure AD, AFAIK it is not possible to do so.
However, in the response along with token you get back a refresh token as well that can be used to get a new token. What you can do is cache the refresh token and expiry time and before making a request you can check if the token has expired (or about to expire). In that case you make use of this refresh token to get a new token and then make your request.
Related
I am using the the oauth2 library to impersionate a service account with a user in order to access the google api in the context of that user similar to this example:
function getService() {
return OAuth2.createService('GoogleDrive:' + USER_EMAIL)
// Set the endpoint URL.
.setTokenUrl('https://oauth2.googleapis.com/token')
// Set the private key and issuer.
.setPrivateKey(PRIVATE_KEY)
.setIssuer(CLIENT_EMAIL)
// Set the name of the user to impersonate. This will only work for
// Google Apps for Work/EDU accounts whose admin has setup domain-wide
// delegation:
// https://developers.google.com/identity/protocols/OAuth2ServiceAccount#delegatingauthority
.setSubject(USER_EMAIL)
// Set the property store where authorized tokens should be persisted.
.setPropertyStore(PropertiesService.getUserProperties())
// Set the scope. This must match one of the scopes configured during the
// setup of domain-wide delegation.
.setScope('https://www.googleapis.com/auth/drive');
}
As you can see, I am storing the bearer token in the Userproperties and I am wondering if this has some security implications.
Can the user access this token somewhere (afaik there is no UI in the Gsuite for that?)
What can the user actually do with this token (I think it will expire in 1 hour right?)
From the discussions on the comments, I would like to propose the following answer as the current answer.
Q1
Can the user access this token somewhere (afaik there is no UI in the Gsuite for that?)
A: When PropertiesService.getUserProperties() is used, the user can retrieve the saved values on only the same GAS project. And, it seems that the values cannot be retrieved with the Google APIs and UI. Ref
Q2
What can the user actually do with this token (I think it will expire in 1 hour right?)
A: At Google, the default value of expires_in of the access token is 3600 seconds. About this, you can check this using the following curl command.
curl "https://www.googleapis.com/oauth2/v3/tokeninfo?access_token=###"
Q3
if the user somehow can retrieve this token somehow and use this for getting access to services he should not have access to.
A: For the standalone GAS project, when the users have no permission for writing the script, the users cannot directly see the access token (In this case, users cannot use the log.), while the script can use the user's access token.
Note:
Above situation is for July 10, 2020. Google Apps Script and Google APIs are growing now. So these specification might be changed in the future update. Please be careful this. When I could confirm the specification was changed, I would like to update this answer.
Context: Within an Azure DevOps user's Personal Access Token (PAT) settings, there is the ability to scope the Organization the token has access to and set an Expiration date up to one year.
Question: Is there a way in settings/options to prevent expiration or automate token regeneration? Supplementary question (opinion), is that a bad idea?
Each PAT has a expired date, the default period is 30 days and the maximum period is one year.
If the PAT created at the beginning is 90 day, when it expires, you can choose to change to 180 days or 1 year. But if you start in 1 year and expire soon after one year, you can only add one more token.
In addition ,the following notification is sent - a PAT is near expiration.
This is intended to prevent PAT from being leaked to pose a threat to the user's personal information security in its long-term use.
Updating PAT in a timely manner helps protect your information.
In on premises active directory, how a stale user is defined depends on last logon and last password reset activity. I want to know how to define a user as a stale user after some period of time in azure active directory.
Azure AD does not provide direct feature for identifying stale user.
Below article can help
https://www.undocumented-features.com/2018/06/22/how-to-find-staleish-azure-b2b-guest-accounts/
Below text borrowed from the above blog:
This script uses the RefreshTokensValidFromDateTime property from the user in conjunction with one of the following:
default token refresh lifetime in Azure AD (90 days)
the actual token refresh lifetime if a policy has been configured and is able to be read
a user-specified value
This will help you identify when users last logged on (using the RefreshTokensValidFromDateTimeProperty), and then, based on the tenant’s refresh token setting and a “stale” value (how long you want to specify without a refresh token being updated), lets you calculate a stale user.
Script available at
https://gallery.technet.microsoft.com/scriptcenter/Report-on-Azure-AD-Stale-8e64c1c5
Any help is really appreciated for the following scenario:
How Amazon.com is managing different level of authentication, once at when you visit the site and second when you go to "Your Account"-> "Login & Security" as a security feature?
User logs in (i.e. authenticates) to a website and there is no activity for 7 days. The user revisits the website then user is asked to authenticate again. This can be implemented using cookies but due to security issue, it was implemented using the session token from the server side. After 7 days, when the expired token is provided by the browser, user is challenged to re-authenticate again.
Now, the new requirement is that if the user logs in and visits "Your Account" page then,
if the user still on "Your Account" page and there is no activity for 10 minutes, then user should be challenged to re-authenticate again.
OR.
if the user comes out of the "Your Account" page and revisits the "Your Account" page after 10 minutes, then user should be challenged to re-authenticate again.
So with the token, I can manage only one time period of inactivity, how can I handle multiple states, i.e. state (7 days) and partial state (10 minutes).
What is the industry practice to handle this scenario? Don't want to use cookies as security issue. And as an SSO provider is being used for authentication, use of database will be the last option.
-- David.
How you could handle this is going to boil down to the implementation details of your current expiring session token logic.
A common way to do it is to store your session tokens in a database or in-memory cache. If that's the case, you could simply add a new column that indicates when the user opened the accounts page.
As an example, your new column could be called accountSettingsStartTime. Normally it would have no value, but when the user navigates to the accounts page, it would be populated with the current time. When the user navigates away from the accounts page, you could clear it out. Then, when you check a security token, you just need to check your standard 7 day expiry as well as checking the accountSettingsStartTime column and ensuring it's within the last 10 minutes.
Alternatively, you could give the user a whole new session token with an expiry of 10 minutes when they navigate to account settings, and enforce the usage of that token for operations that involve account settings. You could then check that token when account settings are changed and ask the user to re-authenticate if it has expired (and invalidate their standard 7 day token). Of course, this would require more effort on the client side.
As they say, there's more than one way to skin a cat :)
I have a personal website on which i want to display my latest facebook comment. Everything works fine, but I'm not sure how the access token expiration works. I have a two months access token, so does it mean that every two months I have to get a new access token and replace the one in my code. If so, it's really not convenient at all... especially since all this is to authorize MYSELF to get my OWN comments.
Is there a way to automatically renew the access token or to get a token that doesn't expire or any other way around this two months expiration thing?
According to Facebook documentation you can ping this URL, which will either return the same access token (if there is time left) or a new one (if there is not time left). This will return a string with a token and an expire time.
https://graph.facebook.com/oauth/access_token?client_id=APPID&client_secret=APPSECRET&grant_type=fb_exchange_token&fb_exchange_token=TOKEN