API keys are long-lived project credentials. Keep them on your backend and never include one in browser or mobile application code. Owners and admins can create, rename, scope, and revoke keys; operators and members can inspect them without changing them.
JWT authentication lets your backend issue short-lived credentials instead of distributing an API key to a client. Register only the public signing key with Rhinestone; the private key stays on your backend.Owners and admins manage these keys on the JWT keys screen.
Generate a keypair
Upload a public key
Select Register key, then Generate keypair.
Enter an Integrator ID and Key ID.
Create the key and download the private JWK.
Store the private JWK in a backend secret manager before closing the dialog.
Generate a JWT keypair with sample identifiers.
The dashboard generates an ES256 key on the P-256 curve in your browser. Only the public key is registered. The private key is shown once and cannot be recovered.
Select Register key, then choose the public-key upload option.
Enter an Integrator ID and Key ID.
Paste a public JWK or upload a .json file.
Create the key.
The dashboard accepts RSA keys for RS256 and EC P-256 keys for ES256. It rejects a JWK that contains private key material.
The identifiers map to the tokens your backend signs:
Register a new public key under a new Key ID, start signing with its private key, and wait for tokens signed by the old key to expire. Then open the old key and select Disable. Tokens using a disabled key no longer verify.
The 1auth section appears only in environments where it is enabled. If it is missing, contact Rhinestone to confirm availability. Owners, admins, and operators can manage apps and domains; members have read-only access.
Open 1auth Apps, select Create App, enter a Name, and submit. Open the new app’s row to view its Client ID, domains, and WebAuthn configuration.
2
Add a domain
Under Domains, select Add domain and enter the host name, such as app.example.com, without a scheme, path, or port.For a shared RP ID such as example.com, add both example.com and every host name that will run WebAuthn, such as app.example.com and checkout.example.com. Each must be registered and verified separately; verifying a parent does not verify its subdomains.
3
Publish the DNS record
Copy the Name and Value from the displayed TXT record into your DNS provider. Use the values shown for that domain, not a record copied from another app or environment. If your DNS provider appends the zone name automatically, enter only the relative record name it requires.Select Done if DNS is not ready yet. The pending domain retains its verification instructions in the app drawer.
4
Verify ownership
Once the TXT record is publicly resolvable, select Verify now, or return to the app drawer and select Verify beside the domain. Confirm that the domain’s status changes from pending to active.If verification fails, check the record name and value and allow time for DNS propagation before retrying. If attempts are rate-limited, wait for the interval shown by the Dashboard.
Choose the passkey namespace before onboarding users. For one host, use its host name as the RP ID. To share a namespace across subdomains, use their parent domain.
An established RP ID cannot be changed or cleared in the Dashboard. A different RP ID selects a different passkey, on-chain signer, and smart-account namespace; existing balances do not move automatically. Treat any change as an explicit account migration, not a configuration update.
In the app drawer, find WebAuthn RP namespace and select Configure.
Select a verified domain under RP ID. Only exact, verified domains are eligible; a wildcard domain cannot back this configuration.
In Ceremony origins, enter every authorized HTTPS origin, one per line.
Select Save configuration. For an existing RP ID, use Edit origins to update the origin list without changing the RP ID.
Example configuration in the Dashboard, using sample app data.
https://app.example.com and https://checkout.example.com, on separate lines
An origin includes the scheme and any non-default port, but no path, query, or fragment. Its host name must equal the RP ID or be its subdomain, and must itself be an exact verified domain on this app. Wildcard origins are not accepted. For example, https://app.example.com:8443 is a different origin from https://app.example.com and must be listed separately if used.
Copy the app’s Client ID into clientId in the shared client initializer. It identifies the app; it is not a project API key or JWT signing secret. Keep those credentials on your backend.
Saving an RP ID and ceremony origins authorizes that namespace on the server; it does not activate it in the client. Set the matching webauthn.rpId using Passkeys and domains. Without that option, the SDK keeps exact-host isolation. rpOrigins is server configuration, not an SDK option.
Before onboarding users, authenticate from each deployed origin and confirm that hosts intended to share an account return the same account address. Use the sponsorship setup separately for transaction funding and backend token endpoints.
Owners can invite admins, operators, and members. Admins can invite operators and members. A pending invitation can be resent from the team list.Only owners can change roles. Owners can remove any non-owner; admins can remove operators and members.
