We recently started working on a solution where we want access to user's resources as part of server-to-server calls and authenticated the users with Microsoft work accounts with Azure AD's OAuth 2.0 approach.
We implemented OAuth 2.0 authentication using Microsoft.IdentityModel.Clients.ActiveDirectory Version 2.24 and released in market. About 2 days back, we started getting following errors for some users
"The refresh token has expired because of inactivity for 14 days"
After investigating, We found the following:
By Default, Azure AD refresh tokens are valid for about 14 days.
Access token can only be refreshed for a maximum period of 90 days (given that we "refresh" our refresh token)
90 days after the initial issuance of the access and refresh tokens, the end user will have to sign themselves in again
Currently, these settings are not configurable in Azure AD
In order to solve the issue, we were trying to move to the recently released Microsoft.IdentityModel.Clients.ActiveDirectory Version 3.10. While upgrading from library version 2.24 to 3.10, I was not able to use the RefreshToken that I persisted after serialized using version 2.x, error occurred while doing deserializing with version 3.x (I noticed that the class TokenCache has undergone some changes).
So, I have following questions:
Since, the refresh token in question was getting used to acquire access tokens regularly during the 14 days period, we would like to undertand “What is the definition of "inactivity" for a refresh token?” If it only contains getting access tokens, why did the refresh token expired at the first place? Please note that the call that I was using to get the access token was AuthenticationContext.AcquireTokenByRefreshToken. Could that be the issue? (Link to ADAL 3 didn’t return refresh tokens for ~5 months…
How can I use the persisted serialized 2.x token cache with the library version 3.x?
Given that we move to the version 3.x and use the calls AuthenticationContext.AcquireTokenSilentAsync to get the access tokens on a regular basis, I won't run into the above issue again for a period of 90 days. Can you please confirm the approach I am taking.
Can we get the refresh token for more than 90 days period to avoid asking the user to re-authenticate every quarter?
Do the refresh Token gets invalidated if user changes the password?
It is really late to answer this, by now you may have figured it out the solution. If so, please post your answer.
I had same problem when we shifted to AD 3.10 yesterday and I was missing a call to below line and it worked
var authenticationResult = await authContext.AcquireTokenByAuthorizationCodeAsync(httpCookie.Value, uri, credential);
YOu have to give a call to this before you call authContext.AcquireTokenSilentAsync( ...) Please try at your end .
Related
We have an embedded microApp that is setup on a thirdparty website (Saba) that is designed to pass a session token to our Application. We are initiating a User login by presenting them an embedded browser session using WebView2 in our wpf application. Then after a successful login the microApp on the Saba homepage passes back a session token. This appears to be where the application is hanging, waiting for the valid session token to be returned.
This had been working great up until the last 24 hrs, when we are experience hangs on logging in. It appears that trying to access webview via the console/inspector from Edge doesn't work either. "window.chrome.webview" shows undefined.
We are actively scouring any reference we can find to see if there is information about webview support being deprecated or moved but we haven't yet. If anyone has any ideas or resources of where we may be able to find some answer that would be much appreciated.
We have an app. It does a lot. But the first thing is to sign in to get the name and picture of the user. And we have problem with it.
We have built a website in react and we used 'react-google-login' to sign in the user and get details. But, when we create the build and execute it in cordova, we get error as shown in the code.
gapi.client.load("plus","v1",apiClientLoaded),
gapi.client.plus.pepole.get({
userId:'me'
}).execute(e)//e is another variable
plus should be loaded and we should be able to access people. But, "people is undefined". We have tried adding 'window' also . No change.
Thank you in advance
First, I would advise not using gapi.client.plus since according to google:
Google+ APIs will be shut down on March 7, 2019. This includes Google+ Sign-in and OAuth token requests with Google+ scopes. Google+ integrations for web and mobile apps will also cease to function March 7, 2019. Learn more. This will be a progressive shutdown, with intermittent failures starting as early as January 28, 2019.
Second, The issue is probably with the client not being loaded when your gapi.client.plus.pepole.get({ userId:'me' }).execute(e) code is executed. Try putting this code in the apiClientLoaded callback that you have provided to the gapi.client.load function.
I have an application system that developed based on IdentityServer4 and .NET Core 2.0. Just recently I noticed that log into the server will timeout in 30 minutes regardless of user activity. Client applications cannot launch other SSO enabled applications after the 30 minutes boundary. After 30 minutes, launching any new app will force user login. I looked at the cookies that might affect the SSO functionality, there are three: AspNetCore.Identity.Application, Identity.External and idsrv.session. But they are all browser session cookies. I don’t see how they would timeout. Anyone knows what’s going on?
My related settings:
Absolute Refresh Token Lifetime: 2592000
Access Token Lifetime: 3600
Authorization lifetime 300
Identity Token Lifetime: 300
mode777 is right. This issue is not related to IdentityServer4 nor OpenID Connect. It's related to the AspNetCore.Identity. I find this link very helpful and solved my timeout issue by adding a line like this:
services.Configure<SecurityStampValidatorOptions>(options => options.ValidationInterval = TimeSpan.FromHours(24));
So, what happened is this: After the 30 mins default interval, a request to the server will go through the user security stamp check. For some unknown reason, the logic that checks my user security stamp think the stamp is invalid and hence calls SignInManager's SignOutAsync, which kills everything. What I still don't understand is that my user security stamp is never changed! It shouldn't cause the invalidation. For now, I will let my application works with a much longer check interval, and will keep an eye on the security stamp.
First of all this is not a Identity Server 4 or OpenID Connect related issue. This concerns the local login probably goverened by Asp.Net Identity which is probably Cookie based (It all depends on your configuration - Startup.cs would be nice).
You can configure the session timeout for Asp.Net Identity which is described here: ASP.NET Identity Session Timeout
Have you tried that?
Digging though source code I found that the cause is missing SecurityStamp claim (default name: AspNet.Identity.SecurityStamp) in auth cookie (.AspNetCore.Identity.Application). After 30 minutes (default value for options.ValidationInterval) security stamp is validated against stamp in the store. If it's missing in cookie - validation fails immediately.
So the solution would be to put security stamp in the cookie.
In my case problem was caused because I was using wrong Sign-In method: HttpContext.SignInAsync instead of build-in Asp.Net Identity SignInManager.SignInAsync which is preferable to use in most cases. SignInManager.SignInAsync puts that claim in the cookie.
I used my credentials for create 3 api's in morning but when in noon I tried to create 4th one, application loader fire a message "The application account information was incorrect". I tried to login again button getting same error. My AppleId and Password are correct because I am using same account for login in developer account.
I tried to close loader thrice but hand is still empty.Waiting for your precious suggestion.
Updated Answer:
It's working fine for me now, please try again now
Obsolete Answer:
Based on this
https://developer.apple.com/system-status/
and this https://forums.developer.apple.com/thread/90725
It seems that service is down to few users, therefore, keep patience and wait until the issue is resolved by Apple team.
I have the same issue which started about 90 minutes ago. Earlier this morning I had success uploading.
Updated 29 Oct. 0635Z back end services are working for me now.
I am using ionic framework as a matter of course I use angular.js for front end. on the back end, I use spring-boot for data handling and API management.
I have used a single session and csrf token exchange between client and server.
However, I have been asked to use in some sections one extra security control. as an example one section of application can take as long as server is alive. Another section can stay alive till couple of weeks and another section will ask in every single request or every single.
How can I handle this design problem?
Modern webapps use JSON Web Tokens (JWT)
there is also an angular package you can use.
These tokens are sent with every request and contain arbitrary information about the user or other data. They are issued by your API on successful login and stored in your frontend. The issued token is then attached to every request header when requesting your API. You can then in the backend decode the token and determine if the user has all the required rights to continue, if the token is still valid our outdated for your different use cases.
I am not familiar with your backend solution but i am sure you can find some jwt packages for it or implement an easy solution yourself. (Googling for spring jwt gave quite some results)