Session Validation
Validate session tokens on your server or at the gateway — not in the browser or on the device. After a user signs in, your web or mobile client sends the session token to your API as described in Session management. Your backend (or an API gateway in front of it) must verify the token before serving protected resources.
The same pattern applies to access tokens issued for Inbound Apps and Resources: validate the JWT, then enforce audience and scopes before serving the request.
| Where to validate | Description | |
|---|---|---|
| Backend | Validate server-side on every API request. Recommended for all APIs and when enforcing roles and permissions from JWT claims. | View |
| API gateway | Validate at the edge with AWS, Azure, GCP, or other JWT authorizers — no application code required. | View |
Client apps do not validate sessions
Web and mobile SDKs store tokens and attach them to API requests — see Session management. They do not authorize access; your server does.
Enforce scopes and Resource claims
Validating signature and expiry proves the token is authentic. For APIs protected as Resources, also enforce the authorization claims Descope put in the token:
| Check | Why |
|---|---|
| Signature / project keys | Token was issued by your Descope project |
exp (and nbf if present) | Token is not expired |
aud | Audience matches your API Resource identifier (or your application audience) |
scope | Space-separated scopes include what the endpoint requires |
| Other claims as needed | For example roles, tenant, or custom claims for business rules |
Scopes are defined on the API Resource, not as the primary permission catalog on each Inbound App. Clients request those scopes; Policies and optional RBAC role mapping constrain what can be issued. Granted scopes can also embed mapped roles in the token so APIs can authorize from existing RBAC permissions. See Scopes and roles for how this differs for user-delegated vs M2M tokens.
Recommended order in your gateway or middleware:
- Validate the token (see Backend validation or JWT authorizers).
- Require the OAuth scope for the route, and/or the roles / permissions mapped from those scopes.
- Optionally check other claims for sensitive paths.
- Apply your own business rules (tenant isolation, ownership, and so on).
Example claim shape for a Resource-scoped access token (user or M2M):
{
"sub": "user123",
"aud": ["https://api.example.com"],
"scope": "contacts.read contacts.write",
"roles": ["Sales Rep", "Sales Manager"]
}For gateway-specific scope checks, see JWT authorizers (including FastAPI). For how scopes map to RBAC on a Resource—and what lands in roles for authorization code vs client_credentials—see Scopes and roles.
For live claims on every request (roles, tenant, or custom attributes that may have changed since issuance), use Token introspection via the UserInfo endpoint in addition to local JWT validation.
For the session and refresh token model, see Sessions.
