Authentication

This page covers the identity concepts behind the Hosted sign-in add-on — what your app learns about a user when we run their login, and what it deliberately never learns. Whether they bought through a purchase link on your own website, launched from the marketplace, or just clicked "Sign in with UseThatApp", they arrive through one standard OpenID Connect sign-in. For the step-by-step how-to see Sign in with UseThatApp.

Only if you want us running login

Selling through UseThatApp does not require our login. Apps that keep their own accounts verify purchases with license keys and never touch anything on this page. Read on if you would rather hand us sign-in, passwords, and recovery — then one login gives your app both identity (who the user is, as a privacy-preserving per-app id) and the entitlement call (what they bought, live).

Identity: the pairwise `sub`

When a user signs in, UseThatApp gives you their sub — a pairwise pseudonymous identifier. It is stable for a user within your app, but different in every other app, so it can't be correlated across apps. It is the only identity claim we share: no email, no name, no PII.

Use sub as your local user key — it's persistent across logins for your app.
Key your user records off sub, never an email (we don't share one, and emails change).
Identity is delivered at login (session.sub); it is not in the entitlement response, which only describes the plan.

Who owns what

UseThatApp owns sign-in and the plan. Everything about your product — accounts, roles, data — is yours, keyed on the UseThatApp sub:

Concern	Who owns it
Signing the user in (OpenID Connect)	UseThatApp — a per-app pairwise `sub`
Knowing the user's current plan	UseThatApp (`get_entitlement` — see Licensing)
User accounts, profiles, sign-up	Your app (keyed on the UseThatApp `sub`)
Roles, permissions, multi-user orgs	Your app
Storing per-user data between sessions	Your app

On first sign-in you create a local record keyed on sub; on every later sign-in you look it up. Attach your own roles, settings, and data to that record.

map the UseThatApp sub to your own account
# After complete_login() you have the user's stable per-app sub:
sub = session.sub                       # pairwise, no PII

# Find-or-create YOUR account keyed on sub (never on an email):
user = User.query.filter_by(uta_sub=sub).first()
if user is None:
    user = User(uta_sub=sub)            # your own roles/data hang off this
    db.session.add(user)
    db.session.commit()

Two independent sessions

⚠ "Logged into your app" and "logged into usethatapp.com" are different states.

UseThatApp's session and your app's session are separate by design. UseThatApp signs the user in (yielding the sub and the tokens); your app then runs its own session keyed on that sub. The two have independent lifetimes — your app's session can outlive a single login, and a UseThatApp logout doesn't automatically tear down your app's session (you reconcile that yourself). See Gotchas for the sign-out reconcile pattern.

Free vs paid

A free launch carries no login — an anonymous, token-less visitor is your free tier. A paid launch signs the user in. A user who is already signed into UseThatApp skips the consent screen on launch (seamless SSO), because only an opaque sub is shared. SSO doubles as a signup funnel: a brand-new user signing up on usethatapp.com verifies their email once before a token is issued, then every subsequent login is seamless. (Buyers arriving through a purchase link get their account created during checkout and return with a token immediately — email verification happens afterward, from the receipt email.)

Next Steps