I have a very simple ADFS environment with Angular ADAL app getting the JWT successfully.
No matter what setting i change with "set-adfsproperties", token always expires after one hour.
and that is forcing adal to retrieve a new token each hour.
I would like to token to live for 24 hours to avoid the refresh delay in the UI.
Has anyone been able to change the token expiration beyond the 1hr default?
Try:
Set-ADFSRelyingPartyTrust –TargetName "display name of relying party" –TokenLifetime 1440
To check the new value to make sure it is set do:
Get-ADFSRelyingPartyTrust –Name:"display name of relying party"
See:
ADFS 3.0 using OAuth and Persistent Refresh Tokens
https://blog.fullscope.com/increasing-adfs-token-timeout-time-for-microsoft-dynamics-crm-2011
Related
I'm using directus to grant users access to ressources required by an SPA written in Angular. To authenticate users I created an auth service and interceptor to handle sessions and attach the "Authorization" header. Those services work fine and login as intended. But here comes the problem:
Directus session times are configured with default values (15 min validity for access_token, 7d for refresh_token) but as soon as the access_token expires I cannot retrieve a new one using the refresh token. This bugs me, because the goal is to keep users logged in for the next 7d (refresh_token lifespan) or until logout if they check this option.
My attempts at achieving this:
Since i'm using graphQL, i tried the "auth_refresh" mutation from the authentication documentation. While the access token is still valid, refreshing works fine. After the access token expired there is no way to retrieve a new one via a valid refresh token.
Alternatively I tried to achieve a refresh via the POST request specified by the docs (to double check if it was some sort of config error with graphql) but I encounter exactly the same problems as with graphQL. Directus returns either "401 unauthorized : Token expired."
if i extend the lifespan of the access token for longer than the server defined lifetime,
Response: Sending a token with prolonged life
or "401 unauthorized : Invalid user credentials." if I request a new token without an
"Authorization" header.
Response: Sending no access token
The refresh token is correctly loaded and sent to the server as specified in the docs in both
cases.
Now my questions are:
Am I missing something? I haven't found any further specification in the docs and the Auth0 protocol specifies that a new access token should be retrievable with a valid refresh token.
If this feature is not intended: How could I achieve a "keep me signed in" option with directus? I would like to keep user rights management in one place and do not really want to handle user auth redundantly for my current use case.
2b. Why is the lifespan of the refresh token so much longer than the lifespan of the access token if this isn't intended?
One of my thoughts is, that it has to do with access rights of the "public" role on the "directus_sessions" table. But I can't think of a way to grant only read rights for owned/received tokens, since there are no payload variables available inside the filters. Could this be the cause? Would there be a way to achieve this?
Thx&Greetz
I am using ADB2C (IEF Custom policies and User Flows) to implement signin on a .NET Core WebApp using OpenID (OIDC).
When users login to my app, I am able to check their logged in status using the standard
User.Identity.IsAuthenticated
However, if I close my browser and come back to the app after some time, this logged in status of the user is lost UNTIL I visit the login policy, at which point it auto logs me in.
Is there a simple way to persist the authentication status longer in the cookie so that this step is not needed? I have read in places that there is a way to hold it for 90 days but cant find much info on how to implement this.
In B2C The maximum cookie session time you can configure is 1440 Minutes For Configuring session behavior please go through the document User flows and Custom policy.
Web app session lifetime (minutes) - The lifetime of Azure AD B2C's session cookie stored on the user's browser upon successful authentication.
• Default = 1440 minutes.
• Minimum (inclusive) = 15 minutes.
• Maximum (inclusive) = 1440 minutes.
There is a Keep me signed-in feature which extends the session life time through the use of a persistent cookie. The session remains active after the user closes and reopens the browser. The session is revoked only when a user signs out. The Keep me signed-in feature only applies to sign-in with local accounts. Please refer the document for more information.
Regarding the Persistent tokens lifetime of 90 days it is related to the Azure AD SSO session tokens for that configuration you can refer the document
I am able to allow users to log in to Firebase using email and password. I followed these instructions: https://firebase.google.com/docs/reference/rest/auth/#section-sign-in-email-password
However, after 1 hr it seems the auth expires and I can't use my app anymore. Does anybody know how I can extend that hour? I have read MULTIPLE posts with very similar questions, but I can't find a clear answer. IT seems some people think there is a way to obtain a reauth token or something like that, but still no clear answer.
Manage User Sessions
Firebase Authentication sessions are long lived. Every time a user signs in, the user credentials are sent to the Firebase Authentication backend and exchanged for a Firebase ID token (a JWT) and refresh token. Firebase ID tokens are short lived and last for an hour; the refresh token can be used to retrieve new ID tokens. Refresh tokens expire only when one of the following occurs:
The user is deleted
The user is disabled
A major account change is detected for the user. This includes events like password or email address updates.
Manage Tokens on Web Client
The website client code can call User.getIdToken(forceRefresh?: boolean):
Returns the current token if it has not expired. Otherwise, this will refresh the token and return a new one.
This would need to be called each time a token is sent to the server.
Alternatively, user sessions may be managed via session cookies.
Manage Session Cookies
Firebase Auth provides server-side session cookie management for traditional websites that rely on session cookies. This solution has several advantages over client-side short-lived ID tokens, which may require a redirect mechanism each time to update the session cookie on expiration:
Improved security via JWT-based session tokens that can only be generated using authorized service accounts.
Stateless session cookies that come with all the benefit of using JWTs for authentication. The session cookie has the same claims (including custom claims) as the ID token, making the same permissions checks enforceable on the session cookies.
Ability to create session cookies with custom expiration times ranging from 5 minutes to 2 weeks.
Flexibility to enforce cookie policies based on application requirements: domain, path, secure, httpOnly, etc.
Ability to revoke session cookies when token theft is suspected using the existing refresh token revocation API.
Ability to detect session revocation on major account changes.
Is there a period of life (how long do they expiring) for the oobCodes that Firebase sends with actions like password reset or email verify requests? And can it be configured?
if you are using the Android SDK you should not have to worry about token expiration. The auth and database SDKs talk to each other and the token is automatically refreshed every hour. This should all be invisible to your application.
Are you having some problem where this is not the case?
I've migrated from the legacy firebase to google-firebase. I've semi-private information the access to which was being controlled using tokens with a large expiry time. This has become impossible with the current limitation.
If we use default Auth providers like (Google, Facebook, Email..), updating "SHA-1 key" in firebase console would enable Automatic token refresh.
But in custom authentication, Firebase SDK need to contact 3rd party server to fetch new token.
# Revoke tokens on the backend.
auth.revoke_refresh_tokens(uid)
user = auth.get_user(uid)
# Convert to seconds as the auth_time in the token claims is in seconds.
revocation_second = user.tokens_valid_after_timestamp / 1000
print('Tokens revoked at: {0}'.format(revocation_second))
I am configuring Azure ACS with "Google" configured as IdP in my application. My requirement is that I do not want the IdP login page to be displayed every time I try to log into my application. I have set my ACS token lifetime to the maximum period so that my token is valid for a day.
First time when I log into my application and I select "Stay Signed In" in Google login page, I am able to log into my application. I now close the browser, reopened the application, I am successfully rediercted to the application home page without any credential request. (as ACS internally uses the session token created intenally which will be used in next requests)
But if I do not select "Stay Signed In" in IdP login page, and proceed the same steps, I am asked for credentials. Any idea why is this happening? Is there a way I can manipulate the session token and validate the ACS token which was earlier issued to me ?
When you select "stay signed in" at Google, it writes a persistent cookie, meaning that you'll stay logged in even if you close your browser. By default, your application's cookie is scoped to the session (assuming you're using WIF). When you close and reopen your browser, the original token and cookie are gone. Your browser redirects to ACS, which redirects to Google, which redirects you back again because of the persistent Google cookie. Running your session using Fiddler or HttpWatch should show that, even when you choose "stay signed in", you're still being sent back to ACS and Google and getting a new token.
It sounds like what you want is your RP to "remember" the user so they don't have to log in again within the token lifetime. To do this, your federated cookie (the one with the token in it) needs to be set as persistent, rather than session. If you're using WIF, this can be done using CookieHandler configuration on the FederationAuthenticationModule (see PersistentSessionLifetime).