Hi everyone,
Can JSON WEB Tokens be used safely for a long period of time when offline?
What are the best practices regarding PWA with offline support?
What libraries would you recommend for offline data storage and sync when online?
Thanks in advance
When talking about (offline) PWAs you’ll need to accept that once data hits the client you loose a certain amount of control.
In general all the data stored on the computer of someone else can be accessed by anyone with access to that computer, unless you encrypt it, but don’t hand out the key for the encryption.
JWT in the context of webapps usually means that it gives access to resources you hold (on a server) and by setting a small ttl for the validity you lessen the risk of malicious access if the JWT gets into someones hands it shouldn’t have been.
Applying that to a PWA you can see that the addition of “while offline” essentially makes that discussion obsolete. When offline there’s no connection to resources a JWT could control access to anyways.
Everything you send the client is by definition no longer securable by a token you generate. Once offline the only way to prevent access to data stored on the client-side is by having a secret known to the user (e.g. password), by which data would be encrypted.
But you’ll need to ask yourself how much you need to protect users with access to the PWA from accessing data stored by the PWA. Most often the data stored on the device for offline usage is already content of the user itself, so no access control or a password to “unlock” might actually be enough. You don’t stay logged in social media as well if it’s not your own device you physically control access to.
If the content stored on the PWA is subject to access-control demands of a third parts it get’s tricky. If the third party comes to you and tells you to revoke access to a certain piece of data your hands are tied if the device you put the data on is offline. If the client can read the data once it can read it for as long as your app doesn’t delete the data.
This was about read access. If you’re talking about write access you’ll have the same problem. You can make it difficult, but you cannot prevent write access for a fully client side app. Your only option is to assert write access again, if changes are moved to a computer you control (a.k.a. your server).
The degree by how much you make it difficult to do something you don’t want to happen on the client depends on how much need there is to mitigate the risk of misuse.
Thanks @LostKobrakai for you vision and your opinion on this matter.
When i wrote those questions I was thinking of the following things:
Can someone fake to be offline and gain control over the pwa?
How much data can i store if a user for example writes a blog post
How i can sync the data form the user device with my server when the users comes back online
Chrome devtools allow you to set the network to offline (doesn’t work for websockets at the moment though). Also one can always turn off the network on a computer. About “gain control over the pwa”: You never actually have control for the code running client side. You have control over the source-code, but not what actually runs on the client, especially for something like a PWA/JS, where every browser gives the user a console to execute arbitrary code in. Afaik browser addons also have somewhat access to websites, even though I don’t know any details about that.
To an extend the is true for any software run by the client. See the various ways you can make a paid software work without a valid key. It can be made (very) hard, but not impossible to do such patches.
This is nothing someone else can answer for you. You’ll need to evaluate the tradeoffs here about where to store which data and how. There’s no right way, there’s just the best solution given certain constraints.
This can be as simple as treating it like a form input in a traditional mvc world or as complex as synchronising crdt values. But the complexity lies mostly in how you want to resolve concurrent changes (if they’re possible) and less so in the access control.
Imagine a PWA coming back online and the access was revoked. You’ll probably just deny any changes and not want to sync only the changes the device made while offline until access was revoked. The latter is a really hard problem to solve, as you cannot rely on clocks or really anything to divide changes being done before revokation and after on a device offline at that time.
Yes this is problematic because if i use long life tokens let’s say for 1 month i will need to deal with xss or other attacks that hijack the token.
There is a lot to consider. Also one idea that i had was to use JWKS (JSON Web Key Set) Endpoints from this article
But why do you even need the JWT token when offline? Just let it expire and the next time the client is online refresh it.
Sometimes its better to implement more than one mechanism.
In php, I used to set a $session variable in php, as well as keeping track of the remote address. That away, the session gets deleted, and force the customer to log in if the customer’s remote address/network changed.
Good idea, haven’t thought about that solution.
Thanks for sharing
I live in Europe so for me https://eugdpr.org is a problem regarding users ip and other personal data. If a leak(database memeory etc) happens then I got a new problem on my hands so i tend to stay away from users personal data as much as possible.
While server-side session handling is indeed my preferred way of handling authentication with logins I doubt it’s necessarily a good idea here. Offline first PWAs often use oauth for authentication, because the app itself is not just a user on a website, but it’s own application as well. Often devices are also meant to work like native apps and they’ll generally only ask you for credentials once. As long as you there are means outside the app to revoke access this is a fine solution. Just like a developer might give travis CI access to their github account and you don’t need to re-login every few days.
While I support the intent you might not want to shy away from using the appropriate amount of data for securing your service. Using IPs for e.g. fail2ban blocking is imho a totally reasonably use-case. I’m not a lawyer, but I expect it’s not too difficult to argue in favour of such measures.
When you say ip bans are talking about intruders ai and bots or users that input there password 10 times wrong out of curiosity or ill intent?
Exactly. IP bound sessions can be another security measure to prevent sessions from being used by other IPs than the one starting the session. And with the IPs stored only for the duration of the session you’re not in a place of “I’ll store this for an indefinite time” as well. I guess this is kinda off-topic though.
I think your response is on topic and offers a new solution to the discussion at hand.
Thanks for sharing this idea
You see, that “law” is BS because everybody’s ip is available, even going through a private vpn. Everything is based off of the SIP system (single ip) so its unavoidable, the system always keeps track of ${remoteAddr} in several places.
Maybe you are right. I can argue that for security reasons i should enforce an ip identification for each user
Thanks for your experience and thought on this.
Yea, people don’t realize we have their ip address the second they come onto a web site.
Granted this is going off-topic, but the fact that there’s a technical requirement for IPs (or any kind of data affected) doesn’t make the gdpr rules less needed and useful. Me visiting a website does implicitly give the owner the right to use the IP to handle the request. It doesn’t automatically give them the right to store my IP at hearts desire.
Privacy is not about preventing use of certain data, but about guarding its use to reasonable lengths and also to ensure the subject of the data is informed about the usage and can take educated actions.
Point being: One needs to make conscious decisions about which data to handle/store, document those and inform any affected people about those decisions. You can still data-mine the hell out of your users if you inform them upfront and – depending on your justifications and further laws – asked for concent beforehand.
Should part of the topic be moved when we started talking about ips to something like:
Its a big discussion. But no one has control of ip request except for the user. So the minute they go to a site, they allowed the ip address to be used to service whatever html back to the customer. That is why that law is BS and should be ignored. You see, lawmakers don’t know how the Internet runs, and can’t dictate how it will be used. Sure they can pass as many BS laws about this or that, but they cant change the programming that is established. Beyond that, the customer doesn’t own the ip address.
© Copyright Elixir Forum | Terms | Privacy & Cookies
