Authentication

Tenant apps authenticate every user with a JSON Web Token (JWT). Two things are always true, whatever you build:

• Identity can be Fentrica's or your own. Users sign in with Fentrica-issued credentials, or you bring your own identity provider through JWKS and your users keep their existing login.
• Every token is verified twice — in the Fentrica cloud (broker) and again on the edge device. This is not configurable; verification is layered and end-to-end by design.

Step 1 — Sync your users (start here)

Every tenant app starts with your people. Before a resident, guest, or tenant can control their space, Fentrica needs to know who they are and what they may access — so the first step is always an integration with your system.

We connect to your API — your booking engine, PMS, CRM, or user directory — and sync your users into Fentrica (for example, live hotel bookings that appear and expire as guests check in and out). This backend integration comes first; the app comes after. Getting it right up front is what makes the tenant experience feel effortless: the right people get access to exactly the right spaces, automatically.

Once we have integrated with your API and your users are flowing in, Fentrica issues your credentials — or binds your own identity provider (JWKS) so your users authenticate with the login they already have. When the backend integration is in place, it is provisioned as a service connection, and each site receives its own serviceConnectionId.

Step 2 — Authenticate users in the app

With your users synced, build the tenant app. End users can sign in in one of two ways:

• Fentrica auth web components — drop-in login UI provided by Fentrica; the fastest path.
• Your own login — if you have bound your own identity provider (JWKS), your users sign in with their existing credentials and bring the resulting JWT.

Either way, the JWT that results is what flows through Fentrica to the devices.

Bring your own identity (JWKS)

To use your own identity provider, you register it with Fentrica per organization:

• Issuer — the iss claim your tokens carry.
• JWKS URL — the public endpoint used to fetch your signing keys.

Fentrica selects the right key set from the token's iss claim and the orgId in the request path.

How tokens are verified

Every request is checked in two independent layers, always — there is no cloud-only or device-only mode:

1. Cloud (broker). When a request reaches Fentrica, the broker verifies the JWT's signature against the correct JWKS before routing it.
2. Edge device. The physical controller independently verifies the same token against the issuer's keys before acting on any command — so even inside Fentrica, nothing can act on a user's behalf without a valid token.

Because both layers verify independently, a genuine signature from the identity provider is required the whole way — from the app, through the cloud, to the controller.

Setting it up

User sync, credential issuance, and binding your own JWKS are configured together with Fentrica. Contact [email protected] to get started.

Next steps