Handling offline access for OAuth apps

[asunar]

Any ideas on how to handle offline access for mobile apps that use Google/Facebook/Twitter authentication?

For ex. User creates some data while online after OAuth authentication. Later when she is offline she wants to update data. How will the offline login be handled? Long-lived tokens? If the token is for say -3 days- and she creates data while offline on the last day before expiration, the next day the token expires now she cannot access the data created the day before unless she connects to the OAuth provider and renews the token? Should the app warn the user about upcoming token expirations?

[michielbdejong]

Interesting question!

In an online world, when your server receives requests that have an expired token, your UI would show a "please click here to re-auth" indication, right?

So IMHO, I think the offline-first translation of that, at the moment the user comes back online one day too late, would be to keep showing the "you have unpushed local changes" indication, and add the "please click here to re-auth" indication to that.

If your "you have unpushed local changes" indication has a "try now" button, then that should be disabled and/or show a reference to the "please click here to re-auth" indication.

[gr2m]

yeah +1 what @michielbdejong says. I do that at minutes.io today. I think there is no difference between OAUTH and traditional authentication (say expiring cookies)

[asunar]

Thanks for the responses. It helps to ask what would a connected app do in case of an expired token. Are there any code samples you know that I can take a look?

[gr2m]

The way we handle it in Hoodie is to trigger an "unauthenticated" event, if any request to the server returns a 401 response. The code looks like

hoodie.account.on('unauthenticated', askUserToReauthenticate)

[michielbdejong]

The default remotestorage.js widget would show an "Unauthorized" warning and then a "click here to reconnect" link:

This doesn't answer the problems of interfacing with oauth as we know it today, but we've had the answer for a long time already: signed messages using asymmetric crypto.

Now that browsers are shipping with crypto primitives, we can store keypairs in localstorage/idb and sign messages with those keypairs. It won't matter when we get a message from a user, because the user ultimately controls which messages get signed and published, not the identity provider. Unfortunately this will require changing backend architecture rather substantially, but I suspect that this will be much easier than the balkanized oauth/openid/user+pass authentication landscape we have today.

Once we have a properly decentralized key system in place, it won't matter if users are talking to servers or peers over any kind of data channel, which also fails much more gracefully when the network degrades, the network is only local, or messages are relayed through third-parties.