Concepts
Glossary
The one word these docs use for each concept, what it means and which page explains it.
These docs use one word for each concept. This page lists those words, and every other page links here the first time it uses one.
Each row gives the term, its meaning and the page that explains it in full. The last column lists the words the docs used before. Avoid them in new text. A dash means there is no old word to avoid.
Apps and modules
| Term | Meaning | Where it is explained | Instead of |
|---|---|---|---|
| host app | The Nuxt app that installs Frigear modules and configures them. Pages for app developers may say "your app". | Architecture | host application, consuming app, consuming application |
| hosting platform | Where you deploy the host app, such as Cloudflare, Vercel or a Node server. | Deployment | the host's environment |
| module | A Nuxt module published as @frigear-nu/<name> that adds one feature to a host app. | Modules | building block |
| package | Any npm package in the repository, named in install and publish steps and for tooling that is not a module. | Architecture | — |
| base layer | The shared Nuxt layer a host app extends for config, interface defaults and content pages. Its package is @frigear-nu/base. | Base layer | — |
| options | Module options sit under the module's config key in nuxt.config.ts. Option tables show the full path from that key. | Documentation | — |
| Frigear repository | This monorepo, Frigear-nu/frigear-nu. | Overview | — |
| starter | A ready-made project in .starters/ that you copy to start a new host app, such as the workspace starter. | Installation | boilerplate |
| your workspace | The pnpm workspace a starter creates for you. | Project structure | — |
| frigear.nu | The live Frigear service, which is also the default issuer. | Frigear website app | Frigear SSO |
| Frigear website app | The reference host app in apps/website that runs frigear.nu. | Frigear website app | frigear.nu website |
| test fixture | A minimal Nuxt app under test/fixtures/ that installs a module from source so tests can boot it. | Testing | fixture app, test app |
| playground | A dev app under packages/<name>/playground for working on one package. It is not a test fixture. | Scaffold | — |
People and permissions
| Term | Meaning | Where it is explained | Instead of |
|---|---|---|---|
| permission | A resource:action string such as events:manage, registered by a module or the host app. The only thing code checks. | Access control | ability, privilege, right |
| role | A named bundle of permissions in authorization.roles (grant, inherit, requirements, auto). A user holds several. | Access control | role column, user role |
| policy | Code that refines one permission against a record (definePolicy, defineSharedPolicy). It can deny, never grant. | Access control | ability, policy gate, policy hook |
| before hook | authorization:before: the single hook the host app answers to allow or deny any check. Listeners call allow() or deny(). | Access control | policy hook, <module>:authorize |
| sensitive permission | A permission that a wildcard never covers, such as forms:pii. It is granted by name. | Access control | PII scope |
| sessionOnly | A permission setting: only a cookie session may use it, never a token. | Access control | — |
| staff | People your host app lets into management screens and APIs. They are the people whose roles hold the module's permissions, such as events:update; there is no separate staff check. | Access control | back office users, privileged users |
| admin area | The screens under /admin, drawn by the Admin module and gated by admin:access. | Admin | back office, back-office, admin UI, user admin |
admin role | A role name in authorization.roles. It is a name, not a synonym for staff. | Authorization | — |
| route rule | A routeRules entry with permission, authenticated or guest. Auth enforces it on the server. In client mode it only shapes the interface. | Access control | page guard, role guard |
| principal | Who made a request: the signed-in user, how they proved it and the permissions that proof carries. In code it is AuthPrincipal. | Access control | authenticated user |
| signed-in user | The person behind a principal, when only the person matters. | Access control | logged-in user |
| visitor | Someone with no valid credential. | Access control | guest |
The old words ability, staff guard, policy gate and ceiling are gone from the API. The migration guide maps each to its replacement.
Signing in
| Term | Meaning | Where it is explained | Instead of |
|---|---|---|---|
| sign in / sign-in | "Sign in" is the verb and "sign-in" the noun or adjective. Sign up and sign out follow the same pattern. | Authentication | log in, log out, Log in with frigear.nu |
| Sign in with frigear.nu | Auth's built-in sign-in against frigear.nu for previews and local development. Its option is oauth.frigear. | OAuth providers | Log in with frigear.nu, frigear SSO |
| server mode | Auth signs users in on the host app's own server and keeps them in a cookie session. This is the default. | Auth | server-rendered mode, confidential mode |
| client mode | Auth for an app without its own server, such as a single-page application (SPA) or a Capacitor app. It signs in at an issuer and keeps the tokens. | Client mode | SPA mode, public client mode |
| session | A sealed cookie that keeps a person signed in to one host app in server mode. It may do whatever the user's roles allow. | Access control | — |
| issuer | The server where users sign in and which issues tokens to other apps. Frigear's issuer is the OAuth Server module. | Identity | identity provider, Frigear OAuth server |
| OAuth Server | The module that turns a host app into an issuer, always capitalised and linked. | OAuth Server | — |
| OAuth provider | A third-party sign-in service that Auth supports through nuxt-auth-utils, such as GitHub, Google or a generic OpenID Connect server. | OAuth providers | — |
| OAuth application | An app registered at an issuer so its users can sign in through it. It is stored in oauth_applications. | Routes and clients | OAuth client |
| public / confidential | The two OAuth application types, fixed at creation. A confidential one is a server that keeps a client secret, and a public one has no secret. | Identity | public client, confidential client |
| configured client | A public OAuth application defined in the clients option of OAuth Server instead of in the admin area. | Routes and clients | config client, static client |
The routes /login and /register keep their names as code. Quote "Create account" only when you quote the
interface.
Tokens and scopes
| Term | Meaning | Where it is explained | Instead of |
|---|---|---|---|
| API token | A long-lived token a user creates on their account page for scripts and agents. It starts with fnu_ by default. | Auth server API | user API token, personal token |
| access token | A short-lived signed JSON Web Token (JWT) that an issuer gives an OAuth application for a signed-in user. Not a form access token (ffk_), which Forms owns. | Access control | OAuth token, bearer JWT |
| scope | What an API token or an access token may do: a permission, a wildcard, or a named scope that expands to permissions (tickets) or to none (openid). | Access control | permission (for a token's limit) |
Extension points
| Term | Meaning | Where it is explained | Instead of |
|---|---|---|---|
| extension point | A place where one module adds things to another without importing it, either a registry or a hook. | Extension points | plug-in point, contribution point |
| registry | A build-time list that modules add entries to, such as menus, widgets, tabs, permissions, roles, scopes and Model Context Protocol (MCP) tools. | Extension points | virtual registry |
| hook | A runtime hook (Nitro or app) that a module calls and that listeners in the host app or other modules answer, such as authorization:before. | Extension points | — |
| widget area | A named slot where the Widget module renders the components modules add. | Widget | — |
Database
| Term | Meaning | Where it is explained | Instead of |
|---|---|---|---|
| migration | A generated SQL (Structured Query Language) file that changes the database schema. You commit one whenever a module adds or changes tables. | Database | schema change file |
| dialect | The database type a schema is written for: SQLite or PostgreSQL. | Database | — |
| NuxtHub | The module that gives the host app its database and blob storage. Its package is @nuxthub/core. | Database | — |
| Drizzle | The TypeScript object-relational mapper (ORM) that modules use to define tables and generate migrations. | Module Kit database | — |
Tools and acronyms
| Term | Meaning | Where it is explained | Instead of |
|---|---|---|---|
| Nitro | Nuxt's server engine, where server routes, server plugins and hooks run. | Glossary | server runtime |
| PKCE | Proof Key for Code Exchange: a one-time secret that proves the app finishing a sign-in is the app that started it. | Identity | — |
| SPA | Single-page application: a browser app with no server of its own. | Identity | — |
| JWKS | JSON Web Key Set: the public keys an issuer publishes at /.well-known/jwks.json so others can verify its tokens. | Signing keys | — |
| PII | Personally identifiable information (personal data). Permissions such as events:pii guard it. They are sensitive, so wildcards never include them. | Access control | personal data scope, personal-data scope |
| ACL | Access control list. In the starter, NUXT_ACL_ADMINS lists the emails that always get the admin role. | Authentication | — |
How to use a term
Link a term to this page the first time a page uses it, then write it plainly. Put the plain word first and the code name once after it, as the writing rules explain.
Next steps
- Documentation – the writing rules these terms belong to.
- Access control – the permission, role, scope and policy terms in context.
- Identity – the signing-in terms across apps.