> ## Documentation Index
> Fetch the complete documentation index at: https://docs.withsutro.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Generated App Security

> How Sutro generated apps resolve authenticated subjects and evaluate SLang auth rules.

Generated apps turn SLang security declarations into runtime authentication and authorization behavior.

## Request Flow

When a request reaches a generated app:

1. The runtime extracts credentials from the request.
2. It validates the credentials and establishes a subject.
3. It resolves principals, roles, groups, and permissions for that subject.
4. It exposes the result to SLang as `@subject`.
5. It evaluates the trigger `auth` block before running the action.

If credentials are missing where authentication is required, the request fails with `401`. If the subject is authenticated but does not satisfy the auth rule, the request fails with `403`.

## Subject Resolution

The generated app can resolve `@subject.entity` only when the token subject matches a SLang entity marked with `subject` and `identity`.

```slang theme={null}
entity User
  subject
  identity email
  fields
    email: EMAIL
    displayName: TEXT?

action CurrentUser(): User
  body
    return @subject.entity

action UpdateDisplayName(displayName?: TEXT): User
  body
    user := @subject.entity
    update user {
      displayName := displayName
    }
    return user

trigger CurrentUser on HttpRequest
  endpoint GET /me
  auth
    @subject is @defined

trigger UpdateDisplayName on HttpRequest
  endpoint PATCH /me
  arguments
    displayName := @request.body.displayName
  auth
    @subject is @defined
```

The `identity email` declaration tells the generated app which user field is used for registration and login. The runtime also tracks the internal `@id`, which lets `@subject.entity` fetch the persisted user row.

## Principals, Roles, and Permissions

Principals are security facts about a subject. Roles and permissions are derived from the model relationships declared in SLang:

* `group @id` marks an entity whose instances can scope permissions.
* `role roleField` marks the enum field that carries a role.
* `permissions Subject->relationPath->roleValue` grants permission strings to that role.

At request time, generated apps use those declarations to build `@subject.roles` and principal permissions. Trigger auth checks such as `@subject can "project:read" in Organization(@request.path.organizationId)` are evaluated from that runtime subject context.

## Generated Auth Endpoints

Subject declarations enable generated auth endpoints:

* `POST /register`
* `POST /login`
* `POST /refresh`
* `GET /.well-known/jwks.json`

Registration and login use the identity field declared in SLang. For `identity email`, clients send the user's email as the `identity` value.

## Practical Guidance

Keep auth checks at the trigger boundary for coarse access control, and keep ownership checks inside actions for record-level safety. For example, a trigger can require `@subject is @defined`, while the action uses `single Document where @id == documentId and owner == @subject.entity`.