Nox Downloads

Customer Area Shop Now

Core Concepts

Step-by-step setup and troubleshooting guidance for premium WordPress plugins and licensing workflows.

Nox App Connect Version 1.0.0 4 minutes read Updated 1 day ago

Before using Nox App Connect in real projects, it’s important to understand how the core pieces fit together. This section explains the key building blocks of the plugin in plain terms, so you can:

  • Configure clients correctly
  • Choose the right authentication flow
  • Control what external apps can access

How Everything Fits Together

At a high level, Nox App Connect works like this:

  1. You create a client (an external app)
  2. The client requests access using a grant type
  3. The plugin issues an access token
  4. The client uses that token to interact with your WordPress site

Each of the concepts below represents a part of this flow.

Clients (External Applications)

A client is any external application that connects to your WordPress site.

Examples:

  • A mobile app
  • A web dashboard
  • A backend service
  • A third-party integration

When you create a client in App Connect, you are defining:

  • How that app can authenticate
  • What it is allowed to access

Client Types

Public Clients

  • Do not require a client secret
  • Used in:
    • Mobile apps
    • Single-page apps (SPA)

Confidential Clients

  • Require a client secret
  • Used in:
    • Backend services
    • Secure server environments

Access Tokens

An access token is a temporary key that allows a client to make requests to your WordPress site. Instead of sending a username and password, the client sends:

Authorization: Bearer ACCESS_TOKEN

Key Characteristics

  • Temporary (expires after a set time)
  • Scoped (only allows specific actions)
  • Revocable (can be invalidated at any time)

What Tokens Contain

When a token is issued, it includes:

  • Granted WordPress capabilities
  • System permissions (like identity access)
  • Access mode
  • Grant type used

These are stored as a snapshot at the time the token is created

Signing Keys

Signing Keys are used by WordPress to sign JSON Web Tokens so that clients can verify the authenticity of a JWT.

Grant Types (Authentication Methods)

A grant type defines how a client requests access. Different use cases require different grant types.

Supported Grant Types

1. Authorization Code (with PKCE)

Best for:

  • Web apps
  • Mobile apps (with deep linking)
  • User login flows

How it works:

  • User logs in via WordPress
  • User approves access
  • Client receives a token

2. Client Credentials

Best for:

  • Server-to-server communication
  • Background jobs

How it works:

  • No user involved
  • Client authenticates using ID + secret

3. Password Grant

Best for:

  • Trusted Mobile App (direct login form)
  • Trusted internal apps only

How it works:

  • Client sends username and password directly

Avoid this for public or third-party apps.

4. Refresh Token

Best for:

  • Keeping users logged in

How it works:

  • Client exchanges a refresh token for a new access token

Important Behavior

  • Grant types are controlled globally in settings
  • Disabled grants:
    • Cannot be used
    • Are removed from clients
    • Revoke existing tokens issued through them

Access Modes (Permission Control)

An access mode defines what a token is allowed to do. It controls how much of the user’s permissions are available to the client.

Available Access Modes

1. Full User Access

  • Token gets all user permissions

Use when:

  • You fully trust the client

2. Restricted (Recommended)

  • Token gets only selected permissions

Use when:

  • You want control over what the client can do

3. Login Only

  • Token cannot access normal WordPress data
  • Only used for identity endpoints

Use when:

  • You only need authentication (not data access)

Important Rule

Tokens never grant permissions the user does not already have

Token Lifecycle

Understanding how tokens behave over time is important for building reliable integrations.

1. Token Issuance

  • Client sends a request
  • Plugin validates the request
  • Token is created and stored

2. Token Usage

  • Client sends token with API requests
  • WordPress validates:
    • Token exists
    • Token is not expired
    • Token is not revoked

3. Token Expiration

  • Tokens expire after a set time
  • Client must request a new one (or use refresh token)

4. Token Revocation

Tokens can be revoked:

  • Manually (via API)
  • Automatically (e.g., grant disabled)

Identity vs Data Access

Not all tokens behave the same.

Identity Access

  • Used to identify the user
  • Endpoints:
    • /me
    • /userinfo

Data Access

  • Used to interact with WordPress data
  • Example:
    • Posts
    • Users
    • Custom endpoints

JWT vs Opaque Tokens (Advanced)

Opaque Tokens (Default)

  • Random string
  • Validated against database

JWT Tokens (Optional)

  • Self-contained token (JSON Web Token)
  • Signed using RS256
  • Can include metadata

Use JWT when:

  • You need external validation
  • You want stateless verification

Putting It All Together

Here’s a simple example:

  • You create a client for a mobile app
  • The app uses Authorization Code with PKCE
  • A user logs in and approves access
  • The plugin issues a restricted access token
  • The app uses that token to fetch user data

Each step relies on:

  • Client configuration
  • Grant type
  • Access mode
  • Token handling