---
title: Application Verification & Security Policy
category: Security & Applications
order: 6
badge: Security
description: Security verification model distinguishing official platform apps from third-party developer apps.
---

# Application Verification & Security Policy

Security and transparency are foundational to the Ternis identity network. Ternis Auth enforces an explicit verification model that distinguishes **Official Platform Applications** from **Third-Party / Unofficial Developer Applications**.

---

## 1. Official vs. Unofficial Applications

When an application requests authorization on `/oauth/authorize`, the consent interface checks the identity of the developer who registered the OAuth client:

```
                  Client Application Requests Consent
                                  │
                                  ▼
                    Is Creator User an Administrator?
                   (User.is_admin === true || system)
                                  │
                 ┌────────────────┴────────────────┐
                 ▼                                 ▼
             [ YES ]                            [ NO ]
    Official Ternis Application         Unofficial Third-Party App
  - Verified Blue Badge              - Prominent Yellow Warning Alert
  - Trusted Platform App             - Discloses Developer Identity
  - Streamlined Consent              - Explicit Risk Transparency
```

### Verification Criteria

| Classification | Verification Method | Consent Screen Behavior |
| :--- | :--- | :--- |
| **Official Application** | Created by an authorized Ternis Administrator (`User.is_admin = true`). Examples: Ternis Git, Ternis Cloud Console, Account Portal. | Displays a verified badge (`Official Ternis Application`), platform guarantee, and standard requested scope disclosures. |
| **Unofficial Application** | Created by an individual developer, community member, or partner (`User.is_admin = false`). | Displays an amber security warning advising users to verify the application source and discloses the registered developer's name and contact information. |

---

## 2. Unofficial Application Warning Banner

For unofficial applications, Ternis Auth injects an alert into the consent dialogue:

> [!WARNING]
> **Third-Party Application Notice**: This application was created by an independent developer and has not been verified by the Ternis Security Team. Make sure you trust this developer before granting access to your account data.

The consent dialog transparently lists:
- **Developer Name**: The registered display name of the developer account.
- **Support / Contact**: The registered developer's contact channel.
- **Redirect Authority**: The verified host where authorization codes and tokens will be delivered.

---

## 3. Scope Minimization & User Consent

Client applications must follow the **Principle of Least Privilege**:
- Do not request `ternis:admin` or `ternis:partner` unless your application specifically performs administrative or partner-level operations.
- Most standard consumer apps only require `openid`, `profile`, and `email`.
- Users have full visibility into the specific scopes requested and must explicitly click "Authorize" before any tokens are granted.

---

## 4. Security Best Practices for Developers

### 1. Never Leak Client Secrets
- Client Secrets (`client_secret`) must **only** be stored in server-side environments (environment variables, AWS Secrets Manager, Vault).
- Never commit client secrets to git repositories.
- Never embed client secrets in mobile apps, React/Vue SPAs, or browser extensions.

### 2. Mandatory PKCE for Public Clients
- All Single Page Applications (SPAs) and Mobile Apps must use **PKCE (Proof Key for Code Exchange)** with `code_challenge_method=S256`.
- PKCE protects against code interception on public redirect URIs (such as custom mobile URI schemes).

### 3. Secure Token Storage
- Store access tokens and refresh tokens in encrypted, `HttpOnly`, `SameSite=Lax`, `Secure` cookies when operating SSR backends.
- Avoid storing long-lived refresh tokens in browser `localStorage` or `sessionStorage` where they are vulnerable to Cross-Site Scripting (XSS).

### 4. Credential Rotation
- If you suspect a client secret has been compromised, immediately rotate the secret in the [Account Portal](https://account.ternis.org/account/oauth-apps).
- Active tokens can be revoked instantly without deleting the client application.