# Portal Forms Mixed-Auth Security Overview

## Why This Matters
Some forms need users to start with limited access and only unlock full access after sign-in. The platform supports this safely with server-enforced boundaries.

## What Customers Get
- A secure pre-auth experience for allowed starter pages.
- A controlled transition to full-auth pages after successful authentication.
- Consistent behavior when users save and refresh.

## How Security Is Enforced
- Security checks happen on the server for every request.
- Origin allow-lists are validated against configured allowed host URLs.
- Full-auth operations require valid authentication for non-anonymous forms.
- Pre-auth scope cannot use protected operations such as search, protected data retrieval, and document operations.

## Token Flow
- Snippet includes encrypted bootstrap context token.
- Runtime mints short-lived session tokens for active API calls.
- Runtime sends effective token via demToken header (session token preferred, bootstrap fallback for compatibility).
- Requested auth scope is sent in both header and request body for resilience where infrastructure strips custom headers.

## Backward Compatibility
- Existing legacy snippets continue to work.
- Versioned snippets apply stricter origin behavior.
- Migration can be staged without breaking already deployed forms.

## What Customers Must Configure
1. At least one valid allowed host URL per form.
2. Correct authentication provider integration for non-anonymous forms.
3. Snippet redeployment after key auth-mode changes.

These are the key form-level fields added/used for mixed pre-auth to full-auth behavior:

- Is Mixed Auth Enabled
	- Enables mixed-auth mode on a non-anonymous form.
- Anonymous Forms (list of page IDs)
	- Defines which pages are allowed in pre-auth scope.
- Allowed Host Urls (list of origins)
	- Required allow-list for runtime origin validation.

Additional runtime/security metadata carried in the generated snippet token/session flow:

- SnippetVersion
	- Activates stricter versioned runtime behavior.
- AuthScope
	- Runtime scope marker used by server filtering (preAuth/fullAuth).

Important:
- Mixed-auth is intended for non-anonymous forms; anonymous forms should not be used as the mixed-auth boundary mechanism.
- Pre-auth page restrictions and protected operation blocking are server-enforced.

## Recommended Deployment Practice
- Avoid hosting anonymous and non-anonymous forms in the same page runtime where possible.
- If mixed hosting is required, isolate by route or iframe boundary.

## Support Note
If you need a detailed endpoint-by-endpoint control matrix for governance or assurance reviews, this can be provided as a separate artifact.