offline access/authentication | FusionAuth Forum

Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode .

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

offline access/authentication

Scheduled

Pinned

Locked

Moved

Solved

Q&A

911

Loading More Posts

Oldest to Newest

Newest to Oldest

Most Votes

Reply

Reply as topic

Log in to reply

This topic has been deleted. Only users with topic management privileges can see it.

dan

last edited by

I'm building a mobile app that needs to work in places with spotty or no connectivity (think field workers, transit, rural areas).

Can I use FusionAuth as my central identity provider while still letting users authenticate when the device is offline?

FusionAuth - Identity Without Constraints

https://fusionauth.io

1 Reply<br>Last reply

Reply<br>Quote

dan

@dan

last edited by

The cleanest way to do it is with asymmetric JWT verification plus a bounded offline grace period.** Here's the pattern.

FusionAuth signs JWTs with a private key it holds. The matching public key is published at the JWKS endpoint (/.well-known/jwks.json). Your mobile app — or any resource server — can verify a token's signature locally, with zero network calls, as long as it has that public key. You can even bundle the public key with the application and avoid the retrieving it.

That's the property that makes offline auth possible. You're not asking "is this token still good?" over the wire; you're asking "did FusionAuth sign this, and has it expired?" using math the device can do on its own.

See JWT signing configuration and the JWKS endpoint docs.

The Flow

1. First login (online, required). The user authenticates against FusionAuth via OAuth with the offline_access scope, or via the Login API with loginId + password + applicationId. You get back two things:

A short-lived access token (signed JWT, RS256, EdDSA, or ES256)

A long-lived refresh token (opaque, default 30 days, configurable per tenant or application)

Refresh token details are in the refresh token settings docs.

2. Cache the JWKS on the device. Fetch /.well-known/jwks.json once and store it. You'll match incoming tokens to the right key using the kid in the JWT header. For fully air-gapped scenarios, you can bundle the JWKS into the app at build time — see the air-gapping article.

3. Online operation. The app uses the access token for API calls. When it expires, the app calls the Refresh a JWT API with the refresh token to mint a new access token.

4. Offline operation. The app validates the cached access token locally:

Find the key in the JWKS where kid matches the JWT header

Verify the signature with that public key

Check exp, iss, aud, and any custom claims you care about

If the token is past exp but the device is offline, allow a bounded grace period (e.g., 24 hours past expiration). After that, degrade functionality until the device reconnects and refreshes. For instance, you could allow read operations but nothing that changes data.

5. On reconnect. Refresh immediately. If the refresh token has been revoked server-side, the call will fail and the user must re-authenticate.

Token lifetime tuning

This is where you make your security/availability tradeoff explicit. FusionAuth lets you tune both lifetimes per tenant or per application:

Access token TTL (ttl_seconds set this short for online use (5–15 minutes is typical), but if you want longer offline windows without the grace-period workaround, you can extend it. Whatever you pick is the maximum revocation lag for compromised tokens.

Refresh token duration : default is ~30 days. Use a Sliding Window with Maximum Lifetime policy if you want active devices to keep working but inactive ones to expire automatically.

One-Time Use refresh tokens : rotates the token value on every refresh. Strongly recommended — if a refresh token is stolen and used, the legitimate device's next refresh will fail and the theft is detected.

What FusionAuth gives you for revocation

Refresh tokens can be revoked automatically on password change, MFA enrollment, or any action that prevents login. You can also call the Revoke Refresh Tokens API directly. The catch: revocation only takes effect the next time the device tries to refresh. Already-issued access tokens remain valid until their exp.

Tradeoffs you're signing up for

Be honest with yourself about this approach. These aren't FusionAuth limitations, they're inherent to offline auth:

Delayed revocation. A stolen device retains access until the access token expires and the offline grace period elapses. Shorter access token TTLs mean faster revocation but more refresh traffic and shorter offline windows. Pick where on that curve you want to sit.

Clock trust. Offline exp checks rely on the device clock, which the user controls. If that matters for your threat model, store a "last...