docs: OTP within secure enclaves — new security page + updated activity types#583
docs: OTP within secure enclaves — new security page + updated activity types#583turnkeyintern wants to merge 1 commit intotkhq:mainfrom
Conversation
- Add security/otp-enclave.mdx: comprehensive doc covering the enclave-first
OTP architecture (INIT_OTP_V3, VERIFY_OTP_V2, OTP_LOGIN_V2), including
sequence flows, key invariants, client-side security changes from SDK v2026.2.8,
and security controls (bundle sig verification, HPKE encryption, brute-force
protection, inflight limits)
- Update authentication/email.mdx:
- Add callout card linking to new security page with summary of SDK v2026.2.8
client-side security improvements
- Update activity type references: INIT_OTP → INIT_OTP_V3, VERIFY_OTP →
VERIFY_OTP_V2, OTP_LOGIN → OTP_LOGIN_V2
- Expand Breaking Change policy table with VERIFY_OTP_V2 and OTP_LOGIN_V2
version progression
- Update Authorization section to list both enclave (V3) and legacy auth (V3)
paths with correct activity types
- Update authentication/sms.mdx:
- Update How it Works activity types to V3/V2 equivalents
- Add note linking to OTP enclave security page
- Fix sandbox verify/login activity type references
- Update docs.json: add security/otp-enclave to Security tab navigation
References: tkhq/sdk#1220, tkhq/sdk#1221
|
|
||
| ## Enclave-based OTP security | ||
|
|
||
| Starting with SDK `v2026.2.8`, Turnkey's OTP system uses an **enclave-first architecture** where the OTP code is generated, delivered, and verified entirely inside the TLS Fetcher Enclave. The coordinator never sees a plaintext OTP code. |
There was a problem hiding this comment.
OTP system can be changed to OTP flow or OTP signup and login authentication flows
|
|
||
| ## Enclave-based OTP security | ||
|
|
||
| Starting with SDK `v2026.2.8`, Turnkey's OTP system uses an **enclave-first architecture** where the OTP code is generated, delivered, and verified entirely inside the TLS Fetcher Enclave. The coordinator never sees a plaintext OTP code. |
There was a problem hiding this comment.
Do we use the term coordinator extensively in our external facing documentation?? Feels like an internal architectural detail. I do indeed see a couple of instances in our documentation so not a super strong rebuff here, but I wonder if it would be better for general understanding to say something like -- "Turnkey's non-enclave services never see a plaintext OTP code"
| - The client verifies the enclave's bundle signature before trusting the `otpEncryptionTargetBundle` public key | ||
| - OTP attempts are HPKE-encrypted before being sent to the server | ||
| - `publicKey` is now required when encrypting an OTP attempt (no throwaway keypairs) | ||
| - Login/signup sign with the verification token key, not the session key |
There was a problem hiding this comment.
login/signup require a client signature generated using the key passed in during verification, not the session key
| Old: `ACTIVITY_TYPE_INIT_OTP`, `ACTIVITY_TYPE_INIT_OTP_V2`<br/> | ||
| New: `ACTIVITY_TYPE_INIT_OTP_V3` | ||
|
|
||
| **INIT_OTP_AUTH** (coordinator-generated, existing-user login)<br/> |
There was a problem hiding this comment.
I think we're trying to deprecate these
| **INIT_OTP**<br/> | ||
| Old: `ACTIVITY_TYPE_INIT_OTP`<br/> | ||
| New: `ACTIVITY_TYPE_INIT_OTP_V2` | ||
| **INIT_OTP** (enclave-generated, contact verification & signup)<br/> |
There was a problem hiding this comment.
only INIT_OTP_V3 is enclave generated
| 2. `VERIFY_OTP` - verifies the code and returns a verificationToken JWT | ||
| 3. `OTP_LOGIN` - verified the verificationToken and returns a session JWT | ||
| 1. `INIT_OTP_V3` — enclave generates and sends a 6–9 digit or alphanumeric OTP to the specified phone number; the coordinator never sees the plaintext code | ||
| 2. `VERIFY_OTP_V2` — enclave verifies the code and returns a signed verificationToken JWT |
There was a problem hiding this comment.
we should clarify that the verification token from VERIFY_OTP_V2 is enclave generated and signed by TLSF unlike old verification tokens generated by VERIFY_OTP
| description: "How Turnkey generates, delivers, and verifies one-time passwords entirely inside the TLS Fetcher Enclave, ensuring the coordinator never sees a plaintext OTP." | ||
| --- | ||
|
|
||
| Turnkey's OTP system (email and SMS) has been redesigned so that the entire lifecycle of a one-time password — generation, delivery, and verification — happens inside the **TLS Fetcher Enclave**. This page explains the security architecture, the cryptographic invariants that protect your users, and how the SDK enforces them on the client side. |
There was a problem hiding this comment.
OTP system -> OTP flow or OTP signup and login authentication flows
| | Use case | Init activity | Verify activity | OTP generator | | ||
| |---|---|---|---| | ||
| | Contact verification & signup | `ACTIVITY_TYPE_INIT_OTP_V3` | `ACTIVITY_TYPE_VERIFY_OTP_V2` | TLS Fetcher Enclave | | ||
| | Login (existing user auth) | `ACTIVITY_TYPE_INIT_OTP_AUTH_V3` | `ACTIVITY_TYPE_VERIFY_OTP_V2` | Coordinator (legacy) | |
There was a problem hiding this comment.
Need to deprecate the endpoints with AUTH, also cant use VERIFY_OTP_V2 with them
Summary
Adds documentation for the new enclave-based OTP architecture released in SDK
v2026.2.8.What changed
New file:
security/otp-enclave.mdxA dedicated security page covering:
Updated:
authentication/email.mdxINIT_OTP→INIT_OTP_V3,VERIFY_OTP→VERIFY_OTP_V2,OTP_LOGIN→OTP_LOGIN_V2VERIFY_OTP_V2andOTP_LOGIN_V2version progressionsUpdated:
authentication/sms.mdxUpdated:
docs.jsonsecurity/otp-enclaveadded to the Security tab navigation (afterenclave-secure-channels)