---
title: Configuration templates
description: Copy-and-adapt starting points for the three-layer rules of common
  application types — web apps, internal tools, Steam games, CLIs, OIDC relying
  parties, and public apps.
editUrl: true
head: []
template: doc
sidebar:
  order: 5
  hidden: false
  attrs: {}
pagefind: true
draft: false
---

The three layers are flexible, but most applications start from one of a handful of shapes. Pick the closest template below, drop the rules into your application in the [With portal](https://with.sudomimus.com), then adjust.

:::tip[Every layer needs at least one rule]
The model is **allowlist with default-deny**: an application with an empty layer lets **no one** through. A working application needs at least one rule in **each** of the three layers — Authentication, Realize, and Return. If logins are rejected with everything "configured", check that all three layers are non-empty. See the [overview](/en-us/application-rules/overview/) for how the layers compose.
:::

In the tables below, `*.example.com` style values are placeholders — replace them with your own. Each layer can hold more than one rule; within a layer, rules are OR'd.

## Standard web app (passwordless)

Passkeys plus email one-time codes, open sign-up, redirect back to your site. The most common starting point.

| Layer | Rules |
|---|---|
| **1 — Authentication** | `PASSKEY_USERNAMELESS`, `PASSKEY_REASONED`, `EMAIL_VERIFICATION` |
| **2 — Realize** | `EMAIL` → `{ "allowedEmails": ["*"] }` |
| **3 — Return** | `CALLBACK` → `{ "allowedCallbackDomains": ["app.example.com"] }` |

## Web app with social sign-in

The passwordless template plus "Sign in with …" buttons. Add only the providers you want; each is one Layer 1 rule.

| Layer | Rules |
|---|---|
| **1 — Authentication** | `PASSKEY_USERNAMELESS`, `PASSKEY_REASONED`, `EMAIL_VERIFICATION`, `GOOGLE_OAUTH`, `GITHUB_OAUTH`, `DISCORD_OAUTH` |
| **2 — Realize** | `EMAIL` → `{ "allowedEmails": ["*"] }` |
| **3 — Return** | `CALLBACK` → `{ "allowedCallbackDomains": ["app.example.com"] }` |

Note that Steam-, Battle.net-, and X-only accounts have no verified email, so an `EMAIL`-only Layer 2 rejects them. If you offer those providers, pair the `EMAIL` rule with `STEAM_ID` / `EVERYONE` as appropriate (see the public-app template below).

## Internal / team tool (domain-restricted)

Only people with an email on your company's domain may sign in.

| Layer | Rules |
|---|---|
| **1 — Authentication** | `PASSKEY_USERNAMELESS`, `PASSKEY_REASONED`, `EMAIL_VERIFICATION` |
| **2 — Realize** | `EMAIL` → `{ "allowedEmails": ["*@yourcompany.com"] }` |
| **3 — Return** | `CALLBACK` → `{ "allowedCallbackDomains": ["tool.yourcompany.com"] }` |

To force those users through your own identity provider instead of (or in addition to) the gate above, see [Sign in with your IdP](/en-us/domains-federation/sign-in-with-your-idp/) and [Domain login policy](/en-us/domains-federation/domain-login-policy/).

## Steam game (silent, in-game login)

A game shipped through Steam that logs the player in without a browser.

| Layer | Rules |
|---|---|
| **1 — Authentication** | `STEAM_TICKET` → `{ "allowedSteamAppIds": [480] }` |
| **2 — Realize** | `STEAM_ID` → `{ "allowedSteamIds": ["*"] }` |
| **3 — Return** | `DIRECT_ISSUE` |

Replace `480` with your real Steam App ID. To let the same players also sign in through a browser "Sign in with Steam" button, add a `STEAM_OPENID` Layer 1 rule — it resolves to the same Steam identity. End-to-end flow: [Native clients](/en-us/native/overview/).

## CLI / headless service (AccessKey)

A command-line tool or service that authenticates as a known, already-existing account with a pre-issued credential.

| Layer | Rules |
|---|---|
| **1 — Authentication** | `ACCESS_KEY_DIRECT` |
| **2 — Realize** | `SECTOR_SUBJECT` → `{ "allowedSectorSubjects": ["sub_..."] }` (or an `EMAIL` rule that matches the bound account) |
| **3 — Return** | `DIRECT_ISSUE` |

AccessKeys cannot create new accounts — they always act as a specific existing account, so Layer 2 pins that account. See [Native clients](/en-us/native/overview/).

## OIDC relying party

Expose the application to a standard OpenID Connect client (`authorization_code` + PKCE).

| Layer | Rules |
|---|---|
| **1 — Authentication** | `PASSKEY_USERNAMELESS`, `PASSKEY_REASONED`, `EMAIL_VERIFICATION` (plus any social providers) |
| **2 — Realize** | `EMAIL` → `{ "allowedEmails": ["*"] }` |
| **3 — Return** | `OIDC` → `{ "redirectUris": ["https://app.example.com/oidc/callback"], "allowedScopes": ["openid", "email", "profile", "offline_access"], "tokenEndpointAuthMethod": "private_key_jwt" }` |

Use `"tokenEndpointAuthMethod": "none"` for a public client (PKCE is required either way). End-to-end setup: [OIDC relying parties](/en-us/oidc/flow/).

## Desktop app (browser polling)

A desktop or Electron app that opens the system browser for login, then polls for the result.

| Layer | Rules |
|---|---|
| **1 — Authentication** | `PASSKEY_USERNAMELESS`, `PASSKEY_REASONED`, `EMAIL_VERIFICATION` |
| **2 — Realize** | `EMAIL` → `{ "allowedEmails": ["*"] }` |
| **3 — Return** | `STATUS_POLL` |

See the [browser-polling flow](/en-us/native/overview/) for the `/establish` → `/status-poll` → `/redeem` sequence.

## Genuinely public app (no identity gate)

Anyone who can clear Layer 1 is allowed in — including accounts with no verified email (Steam-only, Battle.net-only). Use this when you do not want to restrict *who* can sign in at all.

| Layer | Rules |
|---|---|
| **1 — Authentication** | whichever methods you offer (e.g. `PASSKEY_USERNAMELESS`, `EMAIL_VERIFICATION`, `STEAM_TICKET`, …) |
| **2 — Realize** | `EVERYONE` |
| **3 — Return** | `CALLBACK` / `STATUS_POLL` / `DIRECT_ISSUE` / `OIDC` — whatever your client uses |

`EVERYONE` is unconditional, so it dominates any other Layer 2 rule via the OR semantics. Use it deliberately — see [Realize rules](/en-us/application-rules/realize-rules/).

## After you pick a template

- **Narrow per request.** `/establish` can tighten any layer for a single inquiry via `authenticationConstraints` / `realizeConstraints` / `returnMethods` — useful for, say, an admin-only login link. See the [overview](/en-us/application-rules/overview/).
- **Decide what profile data you request.** Whether the app receives the user's email or name is a separate setting — see [Identity claims and sharing](/en-us/concepts/identity-claims/).
- **Set token lifetimes.** Each rule can override the access- and refresh-token TTLs; leave them `null` to inherit the platform defaults.