shared keys wording update

This commit is contained in:
Madison 2026-07-17 04:48:25 -05:00
parent b48a487a34
commit 81679a1136
2 changed files with 3 additions and 1 deletions

View File

@ -39,6 +39,8 @@ Authentication providers determine how users can sign in to your application. He
For development and testing, Hexclave provides shared OAuth keys that work out of the box. For production, you should set up your own OAuth client credentials. Custom OIDC providers always use your own credentials.
</Info>
A [development environment](/guides/going-further/local-vs-cloud-dashboard) typically uses shared keys. Configure your own client ID and secret in the [cloud dashboard](https://app.hexclave.com) before you launch.
### Shared Keys
Shared keys allow you to quickly get started without needing to register your application with each OAuth provider. These are suitable for development only.

View File

@ -42,7 +42,7 @@ Yes - and you flip each one on or off from the dashboard, no redeploy required.
<AuthMethodsSkeleton />
Use Hexclave's shared development keys for the major providers (Google, GitHub, Microsoft, Spotify) while you build, then swap in your own credentials for production. See [all auth providers](./auth-providers) for setup details.
Shared Hexclave keys work out of the box for Google, GitHub, Microsoft, and Spotify — best for a [development environment](/guides/going-further/local-vs-cloud-dashboard). Swap in your own client ID and secret for production. See [Auth Providers → Shared vs. Custom OAuth Keys](./auth-providers#shared-vs-custom-oauth-keys).
## Can I get the current user anywhere in my app?