Personal data

This page helps you write your privacy notice and answer people’s requests about their data.

Prepare a deployment

Publish your privacy notice as a legal document, and link its public page from your apps and your website. See Publish legal documents. The sections below list what Goiabada stores and shares, for your notice to cover.
Choose how users stay signed in, with Keep users signed in after the browser closes under Admin, Sessions. Always keeps a cookie past the browser’s close without asking, which is yours to decide on: see What’s yours to decide.
Set how long audit events are kept, under Admin, Audit logging, and decide where the servers’ logs go and how long you keep them there. See How long each record is kept.
Decide whether users may delete their own account, with Let users delete their own account under Admin, General, Account deletion. It’s on by default.
Name everyone who receives data in your notice: the apps you register as clients, your mail server, Cloudflare while Turnstile is on, and wherever your logs and backups go. See What apps receive and Who else receives data.

Who is responsible

You are. The organization running a Goiabada deployment decides what it collects about people, why, and on what legal basis, and writes the notices that say so. Running your own copy of Goiabada doesn’t make its maintainers your processor: they never see your deployment or its data. goiabada.dev’s Privacy page covers the website alone.

Installing Goiabada doesn’t make a deployment GDPR compliant, or compliant with any other law. This page gives you the facts to decide with, not legal advice.

Four things are easy to mix up, and each is a different job:

A privacy notice tells people what you do with their data. You publish it as a legal document.
Accepting terms is a user agreeing to a legal document you ask them to accept at sign-in.
The consent screen is a user approving what a client receives about them. See Consent required.
Cookie consent is permission to store or read something in a browser. See Cookies.

Cookies

A stock deployment sets four cookies, two on each server. All four are first-party, set by the server’s own host, and used only to sign people in. Neither server keeps anything else in the browser, and while Turnstile is off, no page loads anything from another site. On a plain http base URL, the names carry no __Host- prefix.

On the auth server

Cookie	What it’s for	How long it lasts
`__Host-authserver`	The user’s session, or a sign-in in progress	30 minutes while a sign-in is in progress. Once signed in, as Keep users signed in after the browser closes decides: see Closing the browser
`__Host-authserver_device`	Lets a new sign-in end the user’s older sessions from the same browser. It signs nobody in	The session maximum lifetime: see How the auth server recognizes a browser

On the admin console

Cookie	What it’s for	How long it lasts
`__Host-adminconsole`	The user’s session in the admin console	Until the browser closes: see Sessions and cookies
`__Host-adminconsole-signin`	The sign-in handshake, from the redirect to the auth server until the user comes back	30 minutes at most

The ePrivacy Directive, in Article 5(3), asks for consent before anything is stored in a browser or read from it, unless it’s strictly necessary to provide a service the user asked for. The Article 29 Working Party’s Opinion 04/2012 on Cookie Consent Exemption (WP194) explains how that exemption applies to cookies that sign a user in.

Goiabada’s cookies are first-party and do nothing but sign people in, the kind of storage that rule exempts. That’s why Goiabada ships no consent banner. Whether your deployment needs one is still yours to decide, under your own law and with what you add.

What’s yours to decide

Always. Under Keep users signed in after the browser closes, Always keeps every user’s sign-in cookie past the browser’s close, without asking them. WP194, section 3.2, says a persistent login cookie isn’t exempt. Under the default, Let each user choose, the cookie outlives the browser only when the user ticks Keep me signed in, the kind of box section 3.2 calls an appropriate means of gaining consent.
Turnstile. While it’s on, the sign-in, forgot-password and registration forms load Cloudflare’s script and frame, so the visitor’s browser sends Cloudflare its data. Cloudflare’s Turnstile privacy addendum says what it does with it. Your notice, and whether to ask first, are up to you. See Require a Turnstile challenge.
Your own templates and static files. They can load anything. A script in the static directory runs, and the Content-Security-Policy restricts only scripts, so fonts, images and stylesheets from other sites load too. An email template can embed a remote image. Whatever you add needs its own consent before it loads. See Change the templates.

Translations can’t load anything: the servers show each translated message as plain text.

What Goiabada stores

Everything is in the auth server’s database, plus the servers’ logs. The admin console keeps nothing of its own: the auth server stores its browser sessions too.

About each user:

their profile: names, username, nickname, website, gender, birthdate, time zone, locale and page language;
their email address and phone number, each with whether it’s verified, and their address;
their password, as a hash, their recovery codes, as digests, and their authenticator’s secret, encrypted;
their picture;
their attributes, groups and permissions;
the consents they gave clients: which client, which scopes, and when;
the legal documents they accepted.

About their sign-ins:

each session’s IP address, the browser’s user agent as it was sent, the device name, type and operating system read from it, when it started and was last used, its ACR level, the clients it served, and a digest of the browser’s device identifier;
each authorization code’s IP address and user agent, from the sign-in it was issued in;
each refresh token’s client, scope, type and times.

Behind each cookie that names a session is a browser-session row, encrypted and with no user column. It holds a sign-in in progress, or a signed-in session. The admin console’s rows hold the user’s tokens, an ID token with their name and email address among them.

Pending registrations, from self-registration, hold an email address until the account is activated.

Audit events name the user by their id, hold digests of email addresses, and on some events an IP address. See the audit log’s details. By default each event is also written to the server’s output, so it lands in your logs too.

The logs hold more. The HTTP request log records each request’s client IP address. It’s off unless you turn it on, but every configuration the setup wizard writes turns it on, and the production checklist asks for it. Some warning and error records name a user by their id, such as a logout token that couldn’t be delivered. Verbose API logging, meant for development, also writes every Admin and Account API body, names and email addresses included. See Logs.

What apps receive

Claims, by scope. /userinfo returns the claims of every OpenID Connect scope in the access token it’s called with, whatever the claims settings say. Those settings only decide which tokens also carry the claims, so turning them off doesn’t keep the claims from an app that holds the scopes. See Where the claims go.
The same subject for every client. sub is the user’s subject, the same in every client’s tokens.
Profile pictures, which anyone who knows the user’s subject can load. See The profile picture.
ID tokens, which apps keep and may send back as id_token_hint when they sign a user out. Sent in a query string, the hint lands in the browser’s history and in proxies’ access logs: Hiding the hint shows how to keep it out.
Logout tokens, naming the user’s sub and, for one session, its sid, sent to each client with a back-channel logout URI. See The logout token.

Who else receives data

Your mail server gets each recipient’s address and the message.
Cloudflare, while Turnstile is on, gets the visitor’s browser data through its widget, on the sign-in, forgot-password and registration forms. The auth server’s own check with Cloudflare sends only the widget’s token and your secret key, not the visitor’s IP address.
Your log pipeline and your backups hold copies of what the servers log and what the database stores.

How long each record is kept

Record	How long it’s kept
Sessions	Until their idle timeout or maximum lifetime, under Admin, Sessions, then the cleanup that runs every 12 hours. See How long a session lasts
Refresh tokens	Until they expire or reach their maximum lifetime, revoked ones included, then the same cleanup. See How long a refresh token lasts
Authorization codes	A code works for 60 seconds, but its row, with the sign-in’s IP address and user agent, stays while any refresh token issued from it lives, up to the offline maximum lifetime. A code with none goes at the next cleanup
Browser-session rows	30 minutes for a sign-in in progress. Once signed in, until the session’s idle timeout or maximum lifetime. Each is deleted within 5 minutes of expiring
Pending registrations	Until the account is activated. One that can no longer be activated goes at the 12-hourly cleanup
Audit events	The retention under Admin, Audit logging, where `0` keeps them forever. See Retention
Logs	Whatever you decide where you collect them
Backups	Until your backups expire

Answering requests

Access and portability. Download the person’s data from their page in Users, or let them download it from their account. Check what the file leaves out before you send it: see A request for a person’s data.
Rectification. Users correct their own details in their account pages, and you on the user’s tabs in the admin console.
Erasure. Delete the user from Users, or let them delete their own account. Deleting users lists what a deletion leaves behind.
Restriction. Disable the user. That ends their sessions, revokes their refresh tokens and sends logout tokens. See Enabled and disabled.
Withdrawn consent. Withdrawing a user’s consent to a client, on their Consents tab or by the user under Account, Consents, revokes that client’s refresh tokens and unredeemed authorization codes for the user. The app keeps what it already received.
Telling apps (GDPR Article 19). That’s a step you take yourself. A logout token ends sessions; it doesn’t ask an app to erase anything. To find the apps that got the person’s data, filter the audit log by their User id: each created_auth_code entry names an app they signed in to. See See what happened.

Next steps

Publish legal documentsPublish your privacy notice and terms, and ask users to accept them.

Users and groupsDeleting users, and answering a request for a person's data.

Audit logEvery security event, how long it's kept and how to find a person's.

Production checklistEverything to check before going live.