Supabase + AuthKit
Connect Supabase + AuthKit to Paycux, step by step, with the exact values to paste on each side.
Introduction
This guide connects Supabase + AuthKit to Paycux over HRIS. Work through it once per organization — each customer gets their own connection, with its own values.
You configure two sides: the application inside the provider, and the connection inside the Paycux dashboard. Neither side is complete on its own, so keep both tabs open.
What Paycux provides
Paycux generates two values for every connection and shows them in the dashboard under the connection's settings. You paste these into the identity provider when you configure the application:
| Value | Where it goes |
|---|---|
| ACS URL | The location the identity provider posts its authentication response to. |
| SP Entity ID | The URI that identifies Paycux as the party making the request. |
Both values are per connection. Do not reuse them across organizations — each organization gets its own connection and its own pair.
What you'll need
Before you start, make sure you have the following in place:
- A Paycux account with access to the project you are configuring.
- An API key for the environment you are working in. Staging keys start with
sk_test_; production keys start withsk_live_. - Admin access on the system you are connecting, so you can create the application and read its metadata.
- A redirect URI registered in the Paycux dashboard under Developer → Redirects.
Add a Paycux third-party auth integration
In Supabase + AuthKit, complete this step before moving on. The values Paycux generated for this connection are on the connection page in the dashboard — copy them from there rather than retyping.
Set up a JWT Template
Access tokens are JWTs signed with a rotating key. Verify them against the JWKS endpoint for your client rather than a pinned public key, so rotation never causes an outage.
1https://api.paycux.com/sso/jwks/client_01M4KXD1PZXFWGWE9ZKPCQRAQ
Cache the key set and re-fetch on an unknown key ID. Reject any token whose issuer, audience or expiry does not match what you expect.
Pass the access token to Supabase APIs
Pass the access token to Supabase APIs applies specifically to Supabase + AuthKit. It behaves the same in both environments, and the values it depends on are visible in the dashboard for the environment you have selected.
If the behaviour you see does not match this description, check which environment your API key belongs to before anything else — a staging key against production data is the most common cause.
Verify the connection
Verify the setup end to end before you hand it to a customer. Run the flow from a private browser window so no existing session masks a broken step.
- 1Open the connection in the dashboard and confirm its status reads Active.
- 2Start the flow from your application, not from the provider, so the redirect URI is exercised.
- 3Sign in as a test user and confirm the profile arrives with an email address.
- 4Check the connection's event list — a successful sign-in appears within a few seconds.
Troubleshooting
If something does not work, check these first — they cover the large majority of failed setups:
- The values were pasted into the wrong environment. Staging and production hold separate configuration.
- A trailing slash or stray whitespace in the ACS URL or redirect URI. Both are matched exactly.
- The connection is saved but not activated. An inactive connection returns
connection_inactive. - Attribute names differ from what the mapping expects, so the user is created without an email address.
Every failed authentication is recorded with a reason on the connection's page in the dashboard. Start there before reading application logs.