For IT
This page sums up what your IT needs to approve the Widget Builder. It describes the app as it is today. How to set up the Widget Builder is described under Register and Sign in.
Sign-in
| Method | What you set up |
|---|---|
| Sign in with Staffbase (default) | Your Staffbase instance must be registered. During registration, a person with the Staffbase role Admin creates an OAuth client in Staffbase Studio. People whose Staffbase role reaches the minimum role (unchanged: Admin) and members of an allowed Staffbase group can sign in. |
| With Microsoft Entra ID, Google, Okta or an OIDC provider | Optional. Your administrators register an application with the provider and enter the provider and client ID under Settings → Technical / IT → Authentication. You can limit sign-in to email domains. People signing in through such a provider only get access if their address is listed under Admin emails (optional). Guide: Add a login provider. |
| With Microsoft through the JASP sign-in app | Only if the installation has switched it on. No app registration of your own. The Widget Builder uses the tenant ID in the Microsoft token to find the tenants that set up a Microsoft provider with this tenant ID. |
| With an email code | Nothing. Only if the installation has set it up. The six-digit code goes to the tenant's contact email address, is valid for 10 minutes and is rejected after 5 failed attempts. |
After signing in with an email code, the session lasts 8 hours. Staffbase decides the session length for Staffbase sign-in.
Readers of the widgets sign in through Staffbase in the default mode signed; the Widget Builder checks the Staffbase token. An administrator can switch on the mode unverified: widgets then load anonymously, and native widgets can use an identity from the Staffbase context that cannot be verified. Treat that information as forgeable. Details: Authentication modes.
Rights in Staffbase
With the person's sign-in (the person's Staffbase token, not the organization's) the Widget Builder reads:
- the person's role and groups (
GET /api/users/{id}), to decide whether they may sign in, - the person's public email address, if the token contains none,
- the name and logo of the instance (
GET /api/branch).
During registration and on Re-register Widgets, the Widget Builder creates and replaces the instance's widget registration with the person's Staffbase sign-in (POST and DELETE on /branch/widgets).
Optional: Staffbase API token. Your administrators can store a Staffbase API token under Settings → Technical / IT; how to create it in Staffbase is described under Staffbase API token. With it, the Widget Builder
- re-registers widgets when a change does not come from your browser (MCP, AI assistant, import),
- searches users, groups, channels, pages and spaces in selection fields.
The Widget Builder checks the token against your instance when you save it (GET /api/branch) and stores it encrypted. The switches under Usage are on after saving. The proxy for API connections does not use this token. If the account moves to a different Staffbase instance, the Widget Builder deletes the token. A log shows every registration and every change to the token for 90 days.
Rights in Microsoft 365
The Widget Builder requests no application permissions in your Microsoft 365. The Widget Builder code contains no call to Microsoft Graph.
Sign-in with your own app. You register the application in your own directory. The Widget Builder requests the scopes you enter in the settings; the default is openid profile email (delegated, on behalf of the signed-in person). Which other rights the app has is up to your registration.
Sign-in through the JASP sign-in app (only if switched on):
| Permission | Type | Purpose |
|---|---|---|
openid | delegated | Sign-in of the person |
email | delegated | Email address, to find tenants with an allowed domain |
SharePoint web part. The package (.sppkg) requests exactly one permission:
| Resource | Permission | Type | Purpose |
|---|---|---|---|
Widget Builder SharePoint | user_impersonation | delegated | The web part signs in to the Widget Builder on behalf of the signed-in person. |
Where you approve the permission is described under Widgets on SharePoint. A person with the Staffbase role Admin connects the tenant in the Widget Builder after the web part has pointed this out. The Widget Builder then stores the Microsoft tenant ID, the app ID, the display name, the allowed SharePoint addresses, the time of the last access and the web part version.
Data
The Widget Builder stores data you create yourselves and data that comes up during sign-in and operation. What passes through the proxy is only kept in the cache (see below). Periods marked "default" can be set differently in an installation; the others are fixed in the code.
| What | Where | How long |
|---|---|---|
| Tenant: name, Staffbase address, contact email address, language | App database | until JASP deletes the tenant |
| Your content: widgets, API connections, data tables with rows, shares, login providers | App database | until you delete it or JASP deletes the tenant |
| Credentials: headers and body of API connections, Staffbase API token, client secret of a login provider | App database, encrypted with AES-256-GCM | like the content; the token until you remove it |
| MCP tokens: name, name of the creator, the first 12 characters; the token itself only as a SHA-256 hash | App database | until JASP deletes the tenant; the token itself is valid for 30 to 365 days (default 90), revoked and expired tokens stay stored as blocked |
| One-time codes for email sign-in: hash of the code, email address, IP address, browser identifier | App database | valid for 10 minutes; deleted after expiry or use, at the earliest 15 minutes after creation (cleanup every 15 minutes) |
Sign-ins through additional providers: identifier (sub), email address, name, role, timestamps, count | App database | until the provider or the tenant is deleted |
| AI conversations (only if AI is switched on) | App database | until the person deletes the conversation or JASP deletes the tenant |
| Widget usage events: user ID, page, country and region (derived from the IP address, not the IP address itself) | Event database | 180 days (default) |
| History of sign-ins and technical events: user ID | Event database | 30 days (default) |
| Change log: user ID, IP address, browser identifier, values before and after the change | Event database | 180 days (default) |
| Active sessions: user ID, IP address, browser identifier | Event database | 60 days after the last activity |
| Daily statistics | Event database | 365 days, cleanup once a week |
| Sent mails (welcome and broadcast mails): recipient, subject, text | App database | 365 days (default), after which a daily run replaces the personal fields with empty values |
| Mail log: every mail sent (sign-in codes, welcome, broadcast and test mails) with recipient, subject and text; codes and tokens in it are masked | App database | 30 days, cleanup every hour |
| Calls through the proxy: responses of the connected services, only if the cache is switched on for the API (default: off) | App memory | for the configured cache time; if the request contains something personal, there is one copy per viewer |
Deleting a single person. The Widget Builder has no function that exports, deletes or replaces the data of a single person in one go. The person's events expire after their periods.
Deleting a whole tenant. JASP does this in the Widget Builder administration. The Widget Builder first cancels the subscription and then deletes in one step the widgets, the MCP tokens, the permission groups, the activated built-in widgets, the Staffbase token with its log, the API connections, the data tables with rows and shares, the login providers and one-time codes, the plugin and SharePoint setup, the AI conversations and the stored mails to the tenant, and finally the tenant itself. It then deletes the tenant's contact email address from the mail log. The deletion is recorded in the change log. Usage events, the history of technical events, the change log, the sessions and the daily statistics of the tenant stay in the event database until their periods expire (see table).
Operations
- The cloud version runs on servers JASP operates at netcup. Production and test run on separate servers. The production address is
https://app.widgetbuilder.de. - Calls to the app go through Cloudflare; JASP reaches the servers for updates through a Cloudflare tunnel.
- All tenants share one database (SQLite). Every row carries its tenant's ID, and the app checks on access that the record's ID matches that of the signed-in tenant.
- The credentials from the table above are stored encrypted (AES-256-GCM). MCP tokens and one-time codes are stored only as hashes.
- The app logs in JSON format. Credential headers (Authorization, Cookie, Staffbase tokens, Referer) and tokens in addresses are masked before writing.
- Error reports go to GlitchTip. The Widget Builder sends no default personal data (IP address, cookies, headers) and masks reports before sending.
- If the installation has switched it on, the builder interface loads a counting script from Umami (
insights.jasp.eu).
Third-party services
| Provider | Purpose | Which data |
|---|---|---|
| Cloudflare | Route to the servers | Calls to the app |
| Staffbase, your instance | Sign-in, role and groups, widget registration, optional search | see "Rights in Staffbase" |
| Microsoft Entra ID | Sign-in with Microsoft; sign-in of the SharePoint web part | see "Rights in Microsoft 365" |
| Microsoft Azure Communication Services | Mails: sign-in codes, subscription and welcome mails | Email address, content of the mail |
JASP Billing (billing.jasp.eu) | Subscription, payment, invoices | Organization name, contact email address |
| AI service (only if switched on for the tenant) | AI assistant in the editor | Conversation and tool results |
| Webhook configured by JASP | Notice of a new registration | Name, contact email address, Staffbase address and ID, time |
| The services you connect as an API | Data for your widgets | whatever you set in the API connection, including the person's tokens if you add them |
The data processing agreement and the list of all service providers are on the JASP website: Data processing agreement (opens in new tab) and Subprocessors (opens in new tab).