Confidential flow on a server

A confidential application keeps its clientSecret on your server and uses it to authenticate the code exchange. If your product has a backend, this is the normal choice: no PKCE to manage, tokens that never touch a browser, and connections tagged with your own user ids. The server-side quickstart shows the calls. What follows is what to store and how to manage the secret.

Tag connections with your user id

Add external_user_id, your own id for the signed-in user, to the auth link. Use the same value when that user connects another website. WOOL uses it to associate those connections with the same user within your application.

One user, many connections

A user may connect several websites, and each becomes its own connection with its own token. The code exchange returns connection_id, user_id, and access_token. This user_id is WOOL's id for the user within your application; external_user_id is the id from your own system.

Store each token under its connection_id, together with the website and your user record. Group the connections by user_id. When you need to run a prompt, pick the connection for the right website and use its token.

Managing the secret

Keep the secret on your backend with your other credentials. To replace it, choose Rotate secret in the application's overview in the console. Copy the new secret when it appears; WOOL shows it once.

The previous secret stops working immediately. Update your backend with the new one before exchanging another authorization code. Your existing connections and access tokens remain valid.

Next steps

Idempotency keeps retries from starting a second run. Re-authorization covers what to do when a website signs a user out.