I am trying to enforce user logout after a period of inactivity, but I have had no luck.
I have a node web application that is using Auth0 and Passport for authentication. I have set the inactivity timeout on the tenant (from the tenant settings page on Auth0) and modified the jwt expiration on the application settings page, but none of these changes have had an effect on the behavior of the application.
Other information: in the application settings, I have set this as a Regular Web Application, and I have tried Basic and Post for Token Endpoint Authentication Method.
I have followed the node JS quickstart guide that Auth0 provides, as well as one of their blog posts using express-session, passport, and passport-auth0. I am configuring express-session and passport in the order that these two posts show, so I don't think that is the issue. I am guessing that there is an extra step needed to implement this functionality, but I can't find any documentation on Auth0's site or Passport's. I am also confused as to why these values are configurable if they don't seem to have any effect.
When I manually set the maxAge value in express-session's settings, I do see the application make a call to Auth0. However, this is not based on inactivity, and that is my primary goal here.
I work with the Auth0 Community and you are able to configure this as a setting with your Auth0 Tenant as described in the below documentation:
The intent of this approach allows the session to go inactive if the
user is no longer present, but otherwise provides a means to trigger
the silent token refresh so that they can continue their session
without the need to be prompted again for credentials.
Inactivity Timer: A rolling timer should be added to the React SDK
wrapper that aligns with the maximum idle lifetime of the Auth0
session. Each time a token is returned to the application the timer
should be reset.
Timeout Modal: When the timer hits 60 seconds from expiration a
timeout modal should render requesting the user to logout or continue
their session.
Continue the session: In the case the user chooses to continue their
session the getTokenSilently() method can be used to request a new
token without needing to redirect the user from the page they are
currently interacting with.
Logging out: In the case the user chooses to logout the logout()
method should be called to assure the Auth0 session is ended as well.
Idle Timeout: In the case that the idle timeout is reached no
immediate action is necessary. To handle the fact that the user may
still be active in another tab, the behavior should not be to log the
user out.
https://auth0.com/docs/sessions/concepts/session-lifetime
I hope this helps you on your quest!
Related
I'm working on a react app where the pages can be used both by authenticated and anonymous users. The pages show more features for the authenticated users.
If a user previously has signed in and revists the website, I want the user to be automatically authenticated, and am struggling to achieve this.
I'm using redirect methods because I don't believe popup is working well on phones (is that assumption correct?).
I have tried storing the homeAccountId in local storage and use that to get the account used and then calling login in the msal instance. I also set up a addEventCallback and listen for EventType.LOGIN_SUCCESS which I use to set some internal state about the logged in user.
I have tried using MsalAuthenticationTemplate but strangely this doesn't invoke a login. I have also tried to detect if this is a "first run" and then invoking the login, but that doesn't work all the time. Sometime I get a SSO error indicating I should provide a login_hint or sid which is not possible because I use B2C.
If I don't do anything the user can click the login button and if the user has a valid cookie with B2C the user is logged in without providing credentials which is a strange behavior for the user because my website indicate the user is not authenticated (and show no logout button).
So I can't really get this to work and are wondering if somebody has a concept for achieving this?
Please checkout the msal-react samples which all demonstrate the behavior you're looking for. The MsalAuthenticationTemplate would be the recommended way to do this and if you're still having issues getting this to work after reviewing the samples I would recommend opening an issue on our repo with code snippets so we can take a closer look at what's going on.
Also using localStorage, if you're not already, would help to maintain application state between browser sessions. sessionStorage is the default.
As for B2C not asking for credentials; server state is separate from client state. You can be signed in on the server without the application knowing about it. Until your application makes a request to the B2C server your application will show that a user is not signed in. If a session already exists on the server when you make a login request, the server may redirect you back to your application without asking for credentials again.
I'm using azure app service built in authentication to log in users to my web app. Since I have some pages that user can access without authentication I have allowed anonymous access in app service auth configuration.
It works as intended for the current session. But when the user closes the browser or opens a new window, the authentication is lost. The user is required to login again.
Is there any way to keep the user logged in?
What I do currently:
On sign in button click,
direct the user to /.auth/login/microsoftaccount, after successful login I call ./auth/me to get the user claims/details and then login the user. Then I do a http post to https://appname.azurewebsites.net/.auth/login/microsoftaccount to validate the tokens that I got from /.auth/me and I also get a session token from this post request (which I don't know what to use for).
I use the custom headers set by the app service for authentication on the backend. App service auth docs
Is this the right way of doing authentication using app service. If so is there any way that we can keep the user logged in to app service auth and not ask them to sign every time they open the website.
Is there any way to cache the tokens?
It is normal that you need to login again after close your browser or open in a new window, because the life cycle of session is from opening the window to closing the window.
You could consider using cookie coordinating with session. Session is on server side, we cannot see it, but we could set the time out value. Cookie is on client side, we could save some authentication information to stay login, but it is not safe.
I am using Microsoft authentication for user but I don't want to keep the user credentials to be saved in cookies so that it should ask every time performing a particular action in application.
I have created a simple web app with external authentication from Microsoft but when a user gets signed in it doesn't ask user for credentials from second time and redirect to RedirectUrl directly because user information is already there in Cookies. Normally this behavior looks fine but I have certain tasks in my Web App which needs authentication from External Source (Microsoft) every time these tasks get performed by user. I tried setting token lifetime in Azure but it says lifetime can not be lesser than 10 minutes.
Note: I can't call signout user because it is not a silent signout.
How can I achieve it?
You can set prompt=login parameter in the authentication request. Then the user should be prompted to re-authenticate even if the user has already been authenticated.
Reference:
https://learn.microsoft.com/en-us/azure/active-directory/azuread-dev/v1-protocols-oauth-code#request-an-authorization-code
https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-js-prompt-behavior
I'm building a new Web API application using OWIN cookie authentication (ASP.NET Identity 2.2) for security.
I'm new to the whole cookies thing, but I've got a head-scratching problem: How is a logged-in user immediately blocked from using the API if their account has been deactivated (either deleted or locked-out)?
This arises after a startling discovery that if I have a user logged in on a client app, and I delete their user account via a different app, they are still able to access the API (i.e. the [Authorize] filter still succeeds because their cookie is still valid).
Somebody please correct me if I'm wrong, but AFAIK, cookies are not stored on the server, so there is no way to "invalidate" the cookie.
Yes, if the user logs out, they won't be able to log back in again. Also, I understand that setting an expiry on every cookie upon successful login will mitigate the problem.
But what about the following scenario: a system administrator (let's call him JoeAdmin) gets fired or otherwise becomes untrusted and some other administrator locks out his account. If JoeAdmin happened to be logged in when he got fired and became disgruntled, he still has access to the system and can do some real damage.
In this scenario, how could JoeAdmin be blocked immediately?
JoeAdmin happened to be logged in when he got fired and became disgruntled
Also JoeAdmin could have saved the cookie value offline, awaiting for his account to be revoked, and then later restores the cookie value to his browser.
OWIN cookie authentication is not ideal if you ever need to immediately invalidate logins.
This is because all the state information about the user is stored client-side, authenticated with a secret only on the server-side.
That said, you could do something with Oauth2 refresh tokens like here. e.g. have an access token that expires after say a minute, which when expired the application has to use a refresh token in order to gain an access token for another minute.
This way, any revoked accounts are only exposed for a short time. However, you may need to deal with the complexity of out-of-sync clocks on client and server.
Long story short, if you need to secure your system in this way, traditional server-side tokens would be the way to go. They are more secure in this regard.
The risks with using OWIN cookies are very similar to those of using JWT's for authentication. See this comment and the associated question and answer.
I am using Azure Active Directory Single Sign On. I want help in following basic questions:
What is the default session timeout once the user login to the site?
Currently we are observing the timeout is very short, how can we increase it?
It really depends on how you secured your site. The most common strategy entails mirroring the validity window of the token used to initiate the session. Assuming you used OpenId Connect, that would be 1 hour.
You can change the default behavior by decoupling the duration of your own session from the validity window of the token. If you are using OWIN middleware, you can pass in the protocol options UseTokenLifetime = false. The same approach will work with both WS-Federation and OpenID Connect middlewares.