I have an ASP.NET MVC5-application, using Azure AD to let Office365 users from different organizations authenticate.
However, if the web application is idle for about 20 minutes, the user is redirected to the login page at the next click/reload. Problem is that the user won't notice this right away, because they are not redirected due to updates on the page are async JS-based...which is then not saved to the database. But when the page is refreshed, they are then redirected to the login.
How do I avoid that login timeout after idle for 20 minutes? I don't really want them to be logged out at all.
Thanks!
It's because the encryption/decryption key for the authentication cookie is being generated on application startup. When the application gets shut down from being idle, the next startup the application can't decrypt previously issued authentication cookies essentially logging everyone out.
You'll need to set the <machineKey /> element in the web.config of your application. You can use a service online to generate it or IIS has a built in machine key generator if you don't trust the online services.
Related
We have 3 applications: admin site running IdentityServer, SPA, webapi with rest services.
On the first one (with IdentityServer) we have some aditional admin ui. A requirement exists that the connected user can seamlessly go from our SPA application to this admin ui without authentication. So, from one web application to the other by redirection.
The question is how to keep both 'sessions' in sync so none expires while at least one is in use?
Example of the problem:
Settings of the apps:
spa_web.com - our spa application -> gets the access token valid for 1 hour and a refresh token.
authorityWithIdServer.com - our id provider site -> has a cookie mantaining session set to 1 hour expiry.
Steps:
1. First we go to spaWeb.com.
2. User needs to be authenticated, so is redirected to authorityWithIdServer.com where he fills out the login form.
3. Using authorization code flow, we are redirected back to spaWeb.com and finnaly get the access token and refresh token which are locally stored.
4. We are using only the spa application for a few hours. Our access token is periodically renewed with the refresh token.
5. Now we decide to go to the admin ui present on the authorityWithIdServer.com.
6. We get the login form again to sign in to that application.
Is it anyhow possible to slide the cookie of authorityWithIdServer.com while we are using spaWeb.com in order not to be forced to login again.
You should not be using refresh tokens in client side apps. Change to authorization code and use the silent (prompt=none in an iframe) way of renewing the token. oidc-client-js implements this out of the box along with session monitoring.
If you do the above then since the renewal request happens in the context of the browser via the authorize endpoint and thus authentication with the IDP is done via cookie then any sliding logic will kick in automatically.
Also note that identityserver4 lets you control how frequently a client must interactively authenticate via the authorize endpoint max_age parameter and the UserSsoLifetime client setting.
I have a SPA App (VueJS) which uses Azure B2C with MSAL to authenticate users. Authentication works just fine.
But what does not work is, that the user is not kept logged in.
As long as i use the app, everything works just fine. But when i start my app the next day i have to relogin (or just reselect the account I want to use), but I would like to have the same user experience like for example the azure portal. I can revisit the portal after one week and do not have to relogin.
How can i achieve this behavior with MSAL? Is this even possible with this library? The library uses the implicit flow.
Is there another library i can use where this works?
Generally, browser-based applications shouldn't keep users logged in, since activity, such as a password change or reset, at the identity provider can invalidate a persistent session and should force an interactive login.
You should consider the "keep me signed in (KMSI)" capability that has been enabled for custom policies.
Before the answer...
I think you'll likely need to expand on what's happening by looking at a network tracing tool. Also, as the other answer said, KMSI will help but likely isn't the only problem here. I recommend looking if the cookie is being set (check below), your app is successfully getting ID, Access tokens, and check this state in subsequent auth requests.
Basics
SSO with MSAL.js is absolutely possible and should occur without much configuration. For some background in browser-based apps implementing authentication, achieving SSO is a factor of cookies/sessions rather than tokens/token management.
How this works
When your single page app redirects the user to the Azure AD B2C sign in page and the end user successfully signs in, Azure AD will set a cookie in the browser of that end user. Then, when your app wants to get an ID token or Access token for the user (assuming the existing one from the initial sign in is expired), MSAL is able to launch a silent i-frame in the background, redirect to the Azure AD site with special query parameters (prompt=none), and utilize the cookie that was set earlier.
I am trying to convert a Drupal 8 site to a progressive web app. I have cached all pages visited by a user using service worker. Is it possible to cache user login so that the user can start using the web app from login page when offline?
Whichever way you implement it, there is always going to be a security risk.
Having said that, similarly to a native application, while you cannot cache the login service for obvious security reasons, you could keep the user's logged in. This means that if they are not logged in, they are unable to login, but if they have already logged in previously while connected, then you could keep them logged in.
If the application is working offline and we require authentication then the risks are that someone gets a hold of the device. Since there is no traffic over the network, then that minimizes the attack surface and there isn't the need to worry about MitM attacks or someone getting a hold of the authentication cookie by sniffing.
I think it would help to understand your exact use for authentication while offline. If we are talking about a shipping cart (or different user journey) i would suggest storing some form of encrypted token (based on the user ID + salt) that would be used to recognize the user. These would be added upon successful login while connected to the internet and used to distinguish which user is currently accessing the site.
If you require authentication to gain access to some confidential data, then I would recommend that you require a connection to view that data so that confidential data is never stored on the device. If it is stored locally, then there is a security risk irrelevant of the authentication you have in place.
I'm using asp.net mvc 5 together with Identity2, standard login/password authentication, with "remember me" checkbox.
Imagine the scenario:
user logs in (standard auth cookie)
application is redeployed
user needs to relogin again.
Questions:
Is it possible not to relogin after deploy?
Sometimes, after deploy when you refreshes a page, that requires authorized access - it displays correctly, but if you refresh the second time - it redirects to login page.
All these happens when deployed to IIS7, locally on IIS Express everything is ok.
The reason that you have to relogin is because the machine key changes. The machine key encryption is used to encrypt and decrypt the authentication cookie. Since the existing cookie cannot be decrypted the user is deemed unauthorized and needs to login again.
To overcome this you can manually set the machine key in the applications web.config
There is a good online tool by Developer Fusion which can generate these for you. Below is an example of one...
<machineKey
validationKey="B4A19ABE93A27433785DD47D6444E4B59394E220641D339AEE453D701F202140FF2BF519CED40335A0563AFB494A48DDF1A8DA00D462B42813712D21342B28C2"
decryptionKey="2488146C1EA8177EB75422FE6FB6188550EBD0E4B67FCFD33056E50AD9771040"
validation="SHA1" decryption="AES"
/>
Now everytime you redeploy the keys never change.
Hope this helps.
We have a JBoss EAP 6.3 cluster with 2 nodes. We also enabled SSO.
The thing is, we got a web application that has the login form, so when the session timeout configured in web.xml expires, it redirects the user to that form. The other web applications deployed, on session timeout are redirecting to that form too.
On one hand we got the session-timeout property in web.xml for every web application, and on the other hand we got the SSO enabled in JBoss.
Is the same session timeout value on all web applications correct ? Should we ignore that value and focus on some SSO global session timeout value? Whats the best practice for configuring the session timeout of every web application in this scenario ?
Thanks guys,
Regards.
The Web session and SSO session are differents things, session is create when you access a web application and this can live without autentication. SSO allows authentication to one resource to implicitly authorize access to other resources.
Then according documentation:
How SSO Works
If a resource is unprotected, a user is not challenged
to authenticate at all. If a user accesses a protected resource, the
user is required to authenticate.
Upon successful authentication, the
roles associated with the user are stored and used for authorization
of all other associated resources.
If the user logs out of an
application, or an application invalidates the session
programmatically, all persisted authorization data is removed, and the
process starts over.
A session timeout does not invalidate the SSO session if other sessions are still valid.
So if you want invalidate sso authtentication across cluster, you may call the method Request.logout(), for example.
SSO Configuration Options:
maxEmptyLife:
Clustered SSO only. The maximum number of seconds an SSO
valve with no active sessions will be usable by a request, before
expiring. A positive value allows proper handling of shutdown of a
node if it is the only one with active sessions attached to the valve.
If maxEmptyLife is set to 0, the valve terminates at the same time as
the local session copies, but backup copies of the sessions, from
clustered applications, are available to other cluster nodes. Allowing
the valve to live beyond the life of its managed sessions gives the
user time to make another request which can then fail over to a
different node, where it activates the backup copy of the session.
Defaults to 1800 seconds (30 minutes).
Se also: Use Single Sign On (SSO) In A Web Application
Another thing is not possible configure a default session-timout value in JBoss 7 (Like jboss 4, 5 and 6) so you'll have to configure this value in each application.
Eg. add in your web.xml:
<session-config>
<session-timeout>20</session-timeout>
</session-config>
I hope this help.