Grants that cascade
A group grants an instance, a database, a table, one generated API of a table, or single fields. Custom and system APIs, events, schedulers and WebSocket events are granted by name.
Security
Access Management
Role-based access down to the field: who can call which API, and which fields they read or write.
Every call carries an API user token, and often a user token for the person behind it. Groups say what they may do: which instances, databases, tables and APIs, and which fields they can read or write. API Maker checks it on every request, and a change to a group applies to the next one.
See it live
Step through it, slow it down, or open the full canvas.
api-maker/features/access-managementLive- Groups
- 3defined
- Allowed
- 0requests
- Denied
- 0401 · 403
- Restarts
- 0after a change
Users get their access from groups. A group allows APIs: generated APIs of some tables or all of them, custom and system APIs. A user can be in several groups.
How it works
Users get their access from groups.
A group allows APIs: generated APIs of some tables or all of them, custom and system APIs. A user can be in several groups.
Only the APIs a group allows.
priya's groups allow reading orders, not deleting them. The delete stops with 403 before anything runs.
Hidden fields leave the response.
Analysts can read name and email of employees, not salary. salary is removed from every response omar gets.
No filtering or writing around the rules.
Querying on salary, or writing email without write access, returns 403 with the field and the group in the message.
No token, no data. Changes are instant.
A request without a valid token gets 401. Give Analysts read on salary and omar's next request already includes it: no restart.
What you get
Field level read and write
Fields without read access leave every response. Writing a field, or filtering on it, without access is refused with 403.
Your users, your table
Sign in the users of your own users table and get a user token. Its groups column says which groups apply; * gives all the groups of the API user.
Other sign-in providers
Accept Google, Azure AD and AWS Cognito tokens, or your own token logic, and map those users to groups too.
Row level rules
Pre hooks restrict the rows a user reaches, for example to their own company, and can be skipped for a group of managers. The APIs Security Report finds tables without one and adds it in one click.
No restart
Change a group and the next request uses it. 401 means the token is missing or invalid, 403 that no group grants the call.
An example
An HR app
Everybody reads names and emails of employees, managers also read salaries, and only HR can change them. Three groups express it, the same APIs serve every screen, and nobody writes permission checks in code.
GET /api/schema/admin/hr/main/employees?select=name,email,salaryx-am-authorization: <API user token of the app>x-am-user-authorization: <token of the person>If the groups of the person can not read salary, the answer comes without it.
POST /api/system-api/admin/token{ "name": "app_users", "u": "[email protected]", "p": "••••••••" }app_users is the name of the auth provider that points to your users table. The answer holds the token, a refresh token and its expiry.
Good to know
- Broad flags like all tables also grant the tables you add later. Prefer naming what a group needs.
- Groups decide which APIs and fields, not which rows: rows are limited by pre hooks. The APIs Security Report shows the tables where no pre hook does it.
Questions
What is the difference between the two tokens?
x-am-authorization identifies the application with an API user created in API Maker. x-am-user-authorization identifies the person, a row of your users table, whose groups column decides which groups apply to the call.
Can an API be public?
Yes. Set its access type to IS_PUBLIC. NO_ACCESS keeps an API for your own code only, TOKEN_ACCESS (the default) needs a token.
Where do API user passwords live?
In API Maker, or in your secret: an API user can read its password from a path of the secret.