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 #

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.
• Active tokens can be revoked instantly without deleting the client application.