Currently my solution has refresh tokens with sliding timeout of 1 hour, and an absolute timeout of 6 hours.
My requirement (which I was given, for the record I don't like this!) is that I must alert the user that their session is about to expire and that they must interact with the system if they want to continue.
Does IdentityServer4 have a mechanism for handling this?
If not, is there a preferred approach to implementing this functionality?
No, there is no built in function for this, its up to the clients to ask for new tokens when they are about to expire.
The easiest solution is to use the IdentityModel.AspNetCore NuGet package and you can read the documentation here
Related
I am using node-oidc-provider library as an OIDC based interface to my auth-service, which eventually does SAML or OIDC based federation with the client. I have a scenario where user can perform e-sign after login.
During e-sign, user needs to re-authenticate him/her-self, and at this time library creates a whole new session with a new grant.
I want this operation with-in the primary login session having limited grant with very short expiry instead of creating a new session.
What could be the best way of achieving this, Have you worked on a similar requirement?
Node-oidc-provider can only have single grant per session which seems to me quite a limitation.
Please HELP! Thanks in advance.
I tried couple of things but seemed to be a hacky approach instead of having something which is close to a standard.
I would consider the following options:
USER SIGN IN
Initial redirect uses scope=openid say. A grant is created, with a 4 hour refresh token and 15 minute access token. It may involve consent.
HIGH PRIVILEGE REDIRECT
Second redirect uses scope=openid payment. Another 4 hour refresh token and short lived access token are created. This replaces the grant, which is pretty standard, but you don't want the payment scope to hang around for long.
SCOPE TIME TO LIVE
The payment scope is assigned a short time to live, of 10 minutes say. When the access token expires, the payment scope is not issued on the next token refresh. Most OIDV providers probably don't support this though.
ALTERNATIVE
The next time the high privilege scope expires, don't refresh it. Instead, just do another redirect with scope=openid. This will usually be an SSO event, so usability is not too bad.
As I am working on implementing a proper auth flow into a react web app, I am presented with different patterns of how to use access and refresh tokens.
I am considering the following two patterns:
Creating some sort of middleware to the fetch API:
This middleware runs before every request to the backend and checks whether the access token is still valid or not.
If it is invalid, it first calls the auth server to fetch a new access (and refresh) token.
Creating an interval which is independent from all other logic to keep the access token alive.
Say if the access token is valid for 5 minutes, the interval will run every 5 minutes to fetch a new access token
I would also make sure it only runs every five minutes, if the user is still active , so that the application left open without any user interaction for a long time will automatically log out
Any API call simply uses the currently active access token and does not need to worry about checking the token first or anything
The second approach seems much much easier and cleaner to implement for me, since it does not add any complexity to fetching data and is completely independent/seperate to the app otherwise.
I've been having a hard time to research this question though tbh. I'm not sure if there is some security issue I'm missing with that approach.
So my questions are:
Is there any security issue with fetching a new access token in an interval from the clients side?
Is there a common practise on how SPA apps (like the react app I mentioned) handle access tokens?
If yes, what is that common practise?
If there is no security issue, are there other cons of the second approach that I am missing out on?
Thank you for your answers in advance!
I think the answer depends, if you always do it every X minutes, and you have many active clients, it might create more load on the backend, compared do doing it on a need basis. Perhaps all clients are not so active all the time?
One thing to look out for is to make sure you don't trigger multiple requests at the same time to request new refresh tokens. If you get a race condition here, then you might be logged out (if you use one-time refresh tokens)
Also it is worth considering to use the BFF pattern, do watch this video
Using the BFF pattern to secure SPA and Blazor Applications - Dominick Baier - NDC Oslo 2021
I tried auth0 and I face a problem where I can't block or force logout a user.
After i blocked a user from auth0 console, The user who was logged in could still access the routes.
I used express-openid-connect middleware and requiresAuth()
I suppose this is a common problem with JWT based service ? and should I implement a statefull session to manage user for these kind of use cases ?
In JWT based services it’s common practice to make the access token lifetime a short one, e.g. 10-15 minutes. That way user can still access the api inside a short window but soon the token needs to be refreshed. And when token refresh takes place the authentication service gets called and can reject granting a new token.
So you can make sure your access token lifetime is short enough and that should be enough to satisfy the security requirements.
It’s of course technically possible that you implement stateful session to check user info on each request but you should not call Auth0 api in this case cause you are going to hit their rate limiter and it slows down your api requests. Some sort of sync to your server side fast read database/cache would be needed.
I am using play framework to develop a web app. Now I need to implement authentication/authorisation without database (really strange requirement). There will only be log in and log out function, no registration. The username/password pair will be authenticated using external service.
Due to limited experience, my current idea is to use token to authenticate and a local file to store username/password.
Is my idea feasible? Is there any recommended libs? If I use token, do I need to pass that token in Http request/response every time and authenticate the token in every controller?
Thanks!
Why store user name and passwords in a local file? I don't see the point and this constitutes a database, which you want to avoid it seems... Deciding to work with local files will be an important limitation if you ever want to deploy more than one server and have some load-balancing done.
Playframework is stateless, meaning that the server doesn't keep session state. To work around that play uses signed session cookies (the browser is storing the session data, and cannot modify it as the session data is signed).
Here's what you can do:
on login: set some data in the session
on each subsequent request, determine the state (logged-in or not) based on the session cookie, see https://www.playframework.com/documentation/2.6.x/ScalaActionsComposition#Authentication
on logout: reset the session cookie
Now this approach has a serious downside, it allows people to replay (reuse) old session cookies to pretend being logged. Another (could be less serious depending on your requirements) is that it is not straightforward to implement session expiration after a certain inactivity.
This is probably enough to answer your question and give you a starting point.
I am looking for a way to invalidate or remove the token that has been issued out to the consumer.
The scenario is when a user's password is changed, we want to make sure all the issued tokens can't not be used anymore.
There's nothing built-in for this other than the normal expiration. If you think about it, how would you implement this? You'd need to make a call to the STS on every call into your server. That's why normally the token expiration is used -- for efficiency. But if you did want to implement this, you could, but it'd be your custom solution.