- Who is this for?
- Backend and mobile developers adding user accounts.
- Before you start
- HTTPS, server-side identity verification and secure device storage.
1. Distinguish application and platform accounts
Signing in to the Uygulama Cloud panel does not provide authentication for your app users. This guide covers your own identity design. Email verification, reset, session and resource permission are separate workflows. Successful sign-in does not authorize access to every project.
2. Assign token responsibilities
Access tokens authenticate API calls; refresh tokens obtain new access through a restricted flow. Store refresh material in device secure storage. Keep tokens out of URLs, analytics and logs. JWT use does not automatically support revocation; define session records or another explicit invalidation mechanism.
| Material | Store | Avoid |
|---|---|---|
| Access token | Short-lived client context | URLs and analytics |
| Refresh token | Secure device storage | General plaintext preferences |
| Privileged key | Server only | Mobile bundles |
3. Coordinate concurrent renewal
Multiple failed requests can trigger competing refresh calls. Share one client renewal task and retry waiting requests only after it succeeds. Track refresh rotation and reuse on the server. Failed rotation should lead to a bounded recovery or sign-in flow, not an endless renewal loop.
4. Complete logout and recovery
Invalidate server-side renewal authority as well as removing local data. Decide how password changes affect other devices. Use expiring, single-use reset material and avoid unnecessary account enumeration. Limit OTP attempts and message sending separately.
5. Enforce ownership for every operation
Do not trust user or project identifiers in the body. Scope queries to the authenticated tenant. If using RLS, verify whether the connected server role bypasses policies. Hiding a button is not an authorization control.
Request → Authentication → Session validity
→ Tenant / resource authorization → Business rule → Data6. Test failure and abuse cases
Exercise cross-user identifiers, revoked tokens, refresh reuse, concurrent renewal, offline logout and account deletion. Device labels are descriptive, not proof of identity. Disconnect notification tokens and queued work from logged-out accounts.
- Never log session secrets.
- Use an appropriate server-side password hash.
- Test cross-user access for each resource.
- Bound login and recovery abuse.
Action summary
- Separate identity from resource permission.
- Design renewal and revocation together.
- Clean up queues and notifications on logout.
Common questions
Is a JWT enough?
No. Expiry, storage, revocation, renewal and authorization remain design responsibilities.
Can a privileged server key go in the app?
No. Client bundles cannot keep server secrets confidential.
Sources and scope
Technical references are listed below. Examples illustrate implementation in your own environment; they are not customer benchmarks or claims of live Uygulama Cloud services. Check the current provider documentation before applying settings.
Sources checked: