Fiuby Developer Documentation

What can I do without a backend?

Welcome players by name, show their picture and personalize the interface. Existing local saves can keep working, but they may disappear when browser data is cleared and do not transfer to another device. Fiuby sign-in does not turn a local save into a cloud save.

Do persistent accounts require renting a server?

No. A backend is the trusted part that verifies identities and manages data securely. Your own server or a suitable managed service can handle it. The service still needs an integration to accept Fiuby sign-in; check the authentication and execution capabilities of its free plan separately. Fiuby does not provide cloud saves or ready connectors for every platform.

How does this differ from Google sign-in?

Google alone does not store game progress either. Sign-in verifies identity; the game or its data service stores saves. Connecting Google directly to your own account system also requires trusted token verification.

The practical difference is ready integrations: services such as Firebase Authentication and Unity Authentication offer connectors that verify Google sign-in and turn it into their own user sessions. Developers can start without writing their own verification server; save storage still needs separate setup. Fiuby currently has no equivalent ready connectors. Its sign-in button is easy, but secure account/save integration takes more work than using a ready Google connector. Choosing Unity or Unreal alone does not remove this requirement.

Link accounts and restore progress

A Fiuby identity and a game account are different things. Fiuby verifies the user; your game database stores scores, levels and saves. Map verified issuer + sub to the account; names, email and login tokens are not save keys. You can add a fiubySub field to a player record, but a browser-supplied ID alone does not prove account ownership. Create the link only after trusted backend verification.

1. When the player first links Fiuby, preserve their current guest game account. Your server connects the verified Fiuby identity to that game account.
2. Signing in with the same Fiuby account finds the old game account. If a different save exists, let the player choose current or account progress; never add scores or overwrite silently.
3. Load the chosen save with your existing game code. Back up both prior saves and ask again if either changes while the choice is open. If you also use other sign-in providers, securely linking them to the same game account should open the same save.

Optional example: a Firebase account bridge

This is a Cloud Functions bridge you deploy to your own project, rather than a ready Firebase sign-in provider. It requires the Blaze plan and cannot be deployed on the Spark free plan alone. Firebase or Cloud Functions is not a general requirement for Fiuby sign-in; another trusted backend can perform verification. The bridge verifies Fiuby tokens and maps the identity to a Firebase UID. For an existing save under another UID, it returns requiresChoice before issuing a Firebase session after the player’s selection.

Follow the included README: change the client ID and deploy functions and database rules to your own Firebase project. The reference uses PixelWar’s score/palette/sketch save model; adapt it to your game. Blaze charges based on usage; review its cost conditions before deployment.

Initialize Firebase and wait for anonymous game auth. showProgressChoice is your game's save picker and returns current, saved or null on cancellation. The package includes progress-choice.js/HTML as a reference. Replace game_saves with your save path.

const fiubyLogin = Fiuby.create({
  clientId: 'YOUR_CLIENT_ID',
  scopes: ['openid', 'profile', 'display_name', 'avatar'],
  locale: 'en'
});
// Button markup: <button id="linkFiuby">Fiuby</button>
const button = document.getElementById('linkFiuby');
button.onclick = async () => {
  button.disabled = true;
  try {
    const session = await fiubyLogin.login();
    const call = firebase.app().functions('europe-west1').httpsCallable('connectFiuby');
    const proof = { accessToken: session.accessToken, idToken: session.idToken };
    let result = await call(proof);
    while (result.data.requiresChoice) {
      const strategy = await showProgressChoice(result.data.progress);
      if (!strategy) return; // Cancel: keep the current session and save.
      result = await call({ ...proof, progressChoice: {
        strategy, revision: result.data.revision, selectionId: result.data.selectionId
      }});
    }
    await firebase.auth().signInWithCustomToken(result.data.customToken);
    const uid = firebase.auth().currentUser.uid;
    const save = (await firebase.database()
      .ref('game_saves/' + uid).once('value')).val();
    // Apply save using your game's existing load function.
  } catch (error) {
    alert(error.message);
  } finally {
    button.disabled = false;
  }
};

If you use your own server

Send the SDK session’s accessToken and idToken to your server over HTTPS. Verify the ID token signature, issuer, audience, expiry and at_hash, then call UserInfo to check current validity and matching sub. Only then create a game session and load the save. A browser-supplied sub or email alone is not proof of identity.