Authentication & Authorization
Configure authentication strategies and entity-level authorization in your Spiderly application.
Authentication Strategies
Spiderly supports two authentication strategies. Both use JWT tokens under the hood — the difference is how tokens are transported between client and server.
Token-Based (Default)
Tokens are returned in the response body and sent via the Authorization header. The client is responsible for storing and managing tokens.
Angular methods:
| Method | Returns | Description |
|---|---|---|
login(request) | AuthResult | Login with email verification token |
loginExternal(provider) | AuthResult | Login with external provider (e.g., Google) |
logout(browserId) | — | Invalidate tokens |
refreshTokenWithHeaders(request) | AuthResult | Refresh an expired access token |
AuthResult includes accessToken, refreshToken, userId, and email.
Cookie-Based
Tokens are stored in HttpOnly cookies — the browser handles storage and sends them automatically. No token management needed on the client side.
Angular methods:
| Method | Returns | Description |
|---|---|---|
loginWithCookies(request) | AuthResultWithCookies | Login with email verification token |
loginExternalWithCookies(provider) | AuthResultWithCookies | Login with external provider (e.g., Google) |
logoutWithCookies(browserId) | — | Clear auth cookies |
refreshTokenWithCookies(browserId) | AuthResultWithCookies | Refresh via cookie |
AuthResultWithCookies includes userId, email, and accessTokenExpiresAt — no tokens in the response body.
Cookie-based authentication requires the AuthGuard attribute's CSRF protection. All state-changing requests (POST, PUT, DELETE, PATCH) must include the X-CSRF: "1" header.
Choosing a Strategy
| Token-Based | Cookie-Based | |
|---|---|---|
| Best for | Mobile apps, cross-domain APIs, SPAs with explicit token handling | Same-domain/subdomain setups, simpler frontend code |
| Token storage | Client manages (localStorage, memory) | Browser manages (HttpOnly cookies) |
| CSRF protection | Not needed (tokens in headers) | Required (X-CSRF header) |
| Cross-subdomain | Works out of the box | Requires CookieDomain and CookieSameSite configuration |
Overview
By default, all entities require authorization for Create, Read, Update, and Delete operations. If your code encounters an authorization issue (e.g., an UnauthorizedException - You don't have the necessary rights to perform the operation.), it means the current user lacks the necessary permissions.
Skipping Authorization: If you want to explicitly bypass authorization for an entity, you can apply the [DoNotAuthorize] attribute. This disables all security checks for that entity across all operations.
If your entity requires access control, follow the steps in this tutorial to configure proper authorization.
Add Permissions to Your Application
Navigate to your ApplicationDbContext.cs file:
Backend\{your-app-name}.Infrastructure\{your-app-name}ApplicationDbContext.csIn the SeedData method, add your entity permissions to the permissions array. Replace YourEntityName with your actual entity name:
private static void SeedData(ModelBuilder modelBuilder)
{
Permission[] permissions =
[
// ... existing permissions ...
// Add your new entity permissions
new Permission { Id = 13, Name = "View YourEntityName", Code = "ReadYourEntityName" },
new Permission { Id = 14, Name = "Edit existing YourEntityName", Code = "UpdateYourEntityName" },
new Permission { Id = 15, Name = "Add new YourEntityName", Code = "InsertYourEntityName" },
new Permission { Id = 16, Name = "Delete YourEntityName", Code = "DeleteYourEntityName" },
];
modelBuilder.Entity<Permission>().HasData(permissions);
// ... rest of seed data ...
}Important: Make sure to use sequential IDs that don't conflict with existing permissions.
After adding the permissions, create and apply a migration:
spiderly add-migration AddYourEntityNamePermissions
spiderly update-databaseAssign Permissions to a Role
In the application UI:
- Navigate to Administration → Roles.
- Select the role you want to modify.
- In the Permissions control, add the newly created permissions.
This ensures users assigned to this role will have access to the specified entity operations.