Mobile tester access

Use a signed enrollment invitation to let an approved tester connect the normal production-default mobile app to a lab or staging environment. The same workflow works for first-party and ISV apps.

Before you create an invitation

Add a public mobile client to the target environment. Its client id must be unique for the application, and its sign-in and sign-out callbacks must use a URL scheme owned by the mobile app, such as com.example.myapp://auth/callback. Mobile clients use authorization code with PKCE and do not have a client secret.

Create and share tester access

1. Open Applications, choose the application, and select Environments.
2. Open Mobile tester access under the target environment.
3. Ask the tester to choose Request test environment in the mobile app and send you the generated enrollment request code within 15 minutes. It is an untrusted request, not device attestation. The private proof is not included and is not shown to the operator.
4. Select Create tester link and paste the request code. TenancyEngine checks that it names this application and an active registered mobile client; you do not select or type an endpoint.
5. Choose a short expiry, then create the one-use link.
6. Let the tester scan the QR code or share the link through an approved private channel.

The QR code and link are shown once. TenancyEngine stores only a hash of the protected token and the device proof's one-way thumbprint. An intercepted link cannot be redeemed from another device without the private proof. Every invitation can be redeemed exactly once by its bound device. Create a separate request and link for each tester or replacement installation. An invitation can be revoked at any time, and the status list shows its expiry and whether it was used. The SDK sends the private proof only in the redemption POST over TLS to the explicitly trusted TenancyEngine authority; it never places the proof in a request code or invitation QR. Credential-bearing redemption bodies cannot be replayed through 307 or 308 redirects. The public endpoint also rejects oversized bodies, tokens, device proofs, and client ids before cryptographic work. The SDK bounds deep-link length and shape before URI parsing or percent decoding and owns a nonredirecting enrollment transport; applications cannot replace that public transport.

What the tester should expect

The mobile app confirms the application and environment before switching. Switching environments signs the user out and clears environment-bound caches before the new profile becomes active. The tester signs in again against the selected environment. Returning to production performs the same cleanup.

Troubleshooting

• No mobile clients: add a public mobile client in this section first.
• Expired or used: create a replacement invitation; the previous link cannot be extended.
• Wrong application: confirm the tester installed the intended app and selected the matching client id.
• Invalid enrollment request: generate a fresh request in the app. Do not paste a thumbprint or edit the request code by hand. Requests older than 15 minutes, more than two minutes in the future, or longer than the supported bound are rejected.
• Configuration incomplete: verify the environment has active HTTPS authority and API URLs and that the mobile client has a custom-scheme callback.

Never put an organization API key, client secret, or manually editable service URL in a mobile app, QR code, or enrollment link.