I’ve been struggling with this issue for quite some time, and I can’t help but think I’m just doing something wrong. I hate the feeling that there’s a better way, and I just haven’t discovered it yet.
When a user opens the app, an online token is generated. As they use the app throughout the day, everything is fine, and of course, the online token expires after 24 hours. This isn’t normally a big deal because they just go through the oauth flow and get a new online token.
The problem occurs when they’re in the middle of paging through a collection, or doing something that requires successive API calls, and the online token expires between calls. The best example is when an online token expires while they’re paging through a collection. When this happens, I have to redirect them back through the oauth flow to get a new online token, which interrupts what they’re doing, and also places them back at the first page of the collection again. This is obviously a pretty poor user experience, but I’m at a loss for a better way.
I’ve seen several people say they only use offline tokens, but I think that’s a bad practice for security reasons (ex. leaked tokens, user permissions, users logging out, etc.) so I’d like to continue using online tokens.
Am I missing something? Is there a better way to handle online token expiry between API calls, such as with paging?
Thanks for any help anyone can offer 
Best way we’ve found is exchange it for a long-lived token, how that’s done depends on your framework/language, but it basically never expires.
Ah right you mention you don’t like that. I suppose then it is a matter of redirecting back through oauth flow? https://shopify.dev/apps/auth/oauth/session-tokens/getting-started
"If your app doesn’t have a offline access token for the shop, then the route should respond with a redirect to send the user to the OAuth login flow. This ensures that the app is installed and receives its shop token.
If your app uses online access tokens, then you need to redirect the user to the OAuth login flow a second time."
Hey @theapemachine ,
We actually used to use just the offline tokens but we ran into an issue with them (can’t remember what to be honest). Using only offline tokens creates a security problem in that offline tokens have full access and don’t respect individual permissions. I suppose we could get permissions at the beginning with their online token, and then switch to the offline after they’ve logged in. Something to think about there maybe.
With a lot of our API calls, expired tokens aren’t a problem because the user just gets sent back for authorization and then comes back to where they were. It’s not ideal to be redirecting the user all over the place since it invites failures, and can be disorienting, but this has been working alright so far.
The real challenge comes when a user is paging through records when the token expires while they’re paging. This breaks their flow and causes frustration. That’s what we’re really trying to solve.
The approach I’m considering at the moment is to use the online token for most calls, and the offline token for operations that require successive calls. Again, this isn’t ideal because it weakens security (which is why we switched from that in the first place).
I’d rather just have a way to rotate the token without forcing the whole oauth flow again, but then that defeats the purpose of oauth.
I just remembered why we couldn’t use only the offline token and had to switch to a mix of offline and online. If you use only the offline token, and you have background jobs, you’ll likely run into a situation where your background jobs are fighting with the front-end for API calls since you’d be using the same token for both.
The solution is to use online tokens for the front-end and offline for the background stuff as stated in the docs. The big problem with this (and something I continually keep running into) is that online tokens expire daily. This leads to them expiring in the middle of calls such as paging and saving, which causes a full re-auth and breaks the user experience.
Any way we could get online token expiry extended to maybe a week or more? 
I thought online tokens were supposed to match the user’s Shopify login session, but they actually expire after 24 hours regardless which makes for a poor user experience.
I’m bumping this because it’s still an issue for me.
The problem is mainly with paging. If an online token expires while a user is moving from page 1 to page 2, it causes them to be redirected back to the oauth flow which is an absolutely horrible experience for users and they regularly complain about it.
Is there no solution for this? I imagine it’s a pretty common problem. I also feel like I must be doing something wrong. Is there an elegant way to handle this that I’m not aware of?
Thanks
1 Like