I'm creating a website that can also be used as a PWA. I'm using JWT for user authentication, and I'm storing the JWT in localstorage. I have a special use case where I need to keep my users logged in for at least 91 days even if a user just logs in once and never uses the site again for the next 90 days. To keep the user logged in for such a long duration, I'll have to set a high expiration time for the JWTs and from what I've read, that's not secure. Is there any way I can achieve my goal without making the site vulnerable?
I'm using Angular 8 and DRF.
Related
I'm looking to secure my electron desktop app with user credentials (username + password), but I'm having a hard time finding the right technology to use. Requirements:
Number of activations can be determined (e.g. x copies of the app can be activated at any given time)
The user can deactivate/revoke access to all active instances remotely.
The activated copy will not need to be re-authenticated manually indefinitely if the user does not log out remotely.
For example, the user can authenticate themself, not use the desktop app for a long time then they aren't expected to log in again when they re-open it.
I am currently looking at JWT as it somewhat satisifes 2. However i've read that it's advised that the tokens not be saved in a database, so if I need to blacklist tokens, the blacklist would be a forever growing collection which is not ideal (unless you had a cronjob to remove expired tokens)
I'm not sure which solution would be ideal here that would meet the requirements.
Use JWT. Create two tokens: access token and refresh token. The access token will be short-lived (minutes), the refresh token will be long-lived (hours, days, weeks). Follow the best practice in token handling (Access token and Refresh token best practices ? How to implement Access & Refresh Tokens). Also comply with the OWASP ASVS V3 requirements regarding session handling
You actually do want the refresh token to expire. Else you would need to hold them in some blacklist forever. Forever is pretty long. Having to delete the expired logs from storage is a small price to pay for this level of flexibility you are willing to implement.
Make the refresh token hold two additional attributes:
Unique identifier
Human readable name
so the user knows which tokens he is invalidating. You would put into the blacklist the unique identifier and the expiration date.
You can identify how many copies of the application are being used based on the active access token count.
I am very new to keycloak and want to use it for SSO, but some of our apps want to have different session expiration length, say App A is 4 hours, App B is 8 hours.
To make this work, I will need to set the keycloak to the shortest expiration time, in this case is 4 hours.
Is this the only way? Or by a long shot, keycloak can treat each client differently?
eg.
Keycloak session set to 16 hours, if request from App A, it will force user to login?
https://keycloak/oicd/login/?client_id=app_a&....
It is not clear what session means in your case. User is logged, when app has valid id/access token, which is usually short lived, e.g. 5 min and app refreshes/renews tokens periodically (for example with refresh tokens). In theory that refresh can be running indefinitely, but actually Offline Session timeouts are applied for refresh token, so it can be limited.
There is also IdP SSO session on top of that, which mean that user/app will get token without asking for user credential, when user is redirected to the IdP login page = user was authenticated recently and it still has that SSO session.
Anyway, Keycloak gives you option to customize session/token timeouts on the realm level:
Some of those timeouts can be overwritten also on the client level:
Note: there can be many dependencies, between all those timeouts, so always test your setup to see how it fits your needs. Example, how it can be complicated: How to specify refresh tokens lifespan in Keycloak
As far as I thought, Instagram does not invalidate access tokens based on their documents. But for a few users of the thousands using one of my applications built on their API, that does not seem to be the case.
I originally referred to the following SO question when initially building the application, and a few others - but I came to the conclusion (or so I thought) that Instagram does not invalidate tokens, which does not seem to be true: Instagram access token expire
Our application makes requests on behalf of a user at specific times of the day. It is an application that users may only need to ever log into once to utilize the service.
Here, for example is a user who signed up 4 days ago - his service was working great until this morning, when testing his access token we were receiving this response:
{"meta": {
"error_type": "OAuthAccessTokenException",
"code": 400,
"error_message": "The access_token provided is invalid."
}}
Why would this be happening on an access token that was valid 4 days ago? We asked the specific user this error is being returned for if he revoked access to our application or anything along those lines, and he did not.
I'm curious if perhaps he changed his IG password which invalidated his access tokens for applications (Although that doesn't seem likely as to what would cause this?)
Does anyone else have experience with Instagram applications randomly invalidating access tokens?
Also, note that 99% of users who have been using our application for a month or more have never had this issue. We've only encountered 3 to 5 other accounts this has happened with.
It's not really random. In fact an access token can be invalided in this 2 cases:
the user changed his password or where forced to do so (when IG thinks your account has been compromised).
they deleted the app the access token is linked to. (Or IG forces the app to be deleted if they suspect spam behavior)
But they do not expire from time.
From own experience the token can expire if:
the user removes the app
the Instagram account gets temporary locked which can happen if the Instagram user logs in from an unknown device/location (e.g. another country). The user is being asked to confirm identity by inserting an SMS code.
The second scenario is probably an Instagram bug. Why would the app token expire each time the account gets temporary locked? Would like to get an answer from Instagram as well.
NOTE: The token does not expire if user changes password.
I'm looking at developing an application using the Yodlee FinApp API.
Their REST protocol requires you to login your users to their system to retrieve data. To do that, you need to send a login and password. A successful request returns you a token that is valid for 30 minutes. Before that 30 minutes elapses, you must log the user in again in order to retrieve a new token. Here's where the problem lies, in my opinion.
I could set something up wherein every time a user logs into my application, I immediately send their login info and password to Yodlee and log them in there as well. Then, I wouldn't need to store their password in my database in plain text. But what happens when 30 minutes elapses? I don't actually "know" their password, so I'm unable to get them a new token and would require them to log in again. It would be a real pain to have users constantly having to log back in every 30 minutes.
Alternatively, I could generate my own password for them when they sign up with my app and use that for my application's interaction with Yodlee. But then I have their Yodlee password stored in my database in plain text. Assuming somebody was able to gain access to my server, they'd have my application's credentials and also all user credentials, so they'd be able to mimic my application's process for logging in and gain access to user transactions. This seems like a bad idea.
What's the correct approach here? It seems like both of the avenues I'm investigating have serious downsides, but maybe I'm missing another option?
#aardvarkk- How are you planning to authenticate the user on your application?
If I understand correctly then you should be storing the user credentials in your application to validate the user and also to check if he/she is a new user or not.
When you would be having this data, you can use the same to login again on behalf of user before 30th minute & only when user will still be in session not every 30 mins.
And we would suggest you to not to store any of the user's credentials in plain texts. You could encrypt it before storing and decrypt before sending it to Yodlee.
Also, the access to your application credentials for Yodlee's production environment is IP restricted and hence only request's coming from your static IP can connect successfully to Yodlee.
[UPDATED]
For this Case:
You can call touchConversationCredentials API which extends the relative (or inactivity) timeout validity of the conversationcredentials i.e. UserSessionToken. You need to pass userSessionToken in this. And you can call this before 29th min of user session to extend his/her session for another 30 mins. But there's an absolute timeout of 120 mins, so after 120 mins of initial session creation it will expire.
First off, really try to avoid storing the user's password in plain text. That is just asking for a world of pain if anything goes wrong (e.g., if you get hacked) and can open you up to all sorts of legal trouble. Truly, don't go that way.
It would in fact be better off if you never learn their Yodlee credentials at all; you don't want to be them, you just want to interact with the system on their behalf.
REST doesn't really say that much about how systems authenticate to one another; many possibilities are available in general. All you can do is try to connect with whatever credentials you have, and if that fails, bail to the user (well, to client-side code) so that they can give you another token. REST does clearly state how a failure to authenticate should be conveyed, a 401 HTTP response, but that's all really.
I am working with Oauth2.0. In that i could able get the access_token and instance_url. Is there any expiry time for these two.
Can I store them and use it for all my REST calls without getting the new access_token and the instance_url. Is it possible for me to use it for long hours or even days.
The access token is only valid for the length of a session (as defined in the Salesforce Org's settings — I believe the longest this can be is 8 hours without activity), as it's actually a session ID, that said, you should also be given a refresh token. The refresh token has a much longer lifetime and can be used to authenticate the user once the session has expired, without them having to enter any credentials — this allows you to do it in the background without them even having to concern themselves with the login process.
model metrics do a good job of explaining the token flow here.