How to Add Sign in With DeadArk

Before you start

Adding Sign in with DeadArk is a standard OAuth 2.1 Authorization Code flow with PKCE. You will need a server-side component to perform the token exchange (never do that in the browser), and somewhere to store a session. If you have integrated any "Sign in with" provider before, the steps below will be familiar.

Step 1 — Register an OAuth client

Register your application as a DeadArk OAuth client. You will configure:

• One or more exact redirect URIs (redirect_uri) that DeadArk is allowed to send users back to.
• The scopes your app needs (request the minimum — typically basic profile).
• Your app's public details (name, logo) shown on the consent screen.

You receive a `client_id` identifying your app. Treat any client secret as a server-only value.

Step 2 — Send the user to authorize (with PKCE)

When a user clicks Sign in with DeadArk, generate a PKCE pair and redirect to DeadArk's authorization endpoint with:

• client_id — your registered client
• redirect_uri — must exactly match a registered value
• response_type=code
• scope — the scopes you need
• state — a random, per-request value you verify on return (CSRF protection)
• code_challenge and code_challenge_method=S256 — your PKCE challenge

Keep the state and the PKCE code_verifier in the user's session so you can use them when they return.

Step 3 — Handle the callback

The user authenticates with their passkey and approves the scopes. DeadArk redirects to your redirect_uri with a code and your state. On the callback:

• Verify `state` matches what you stored. If it does not, reject the request.
• Take the code for the token exchange.

Step 4 — Exchange the code for tokens

From your server, POST to the token endpoint with the code, your client_id, the redirect_uri, and the PKCE code_verifier. You get back tokens, including an access token (and, for OIDC, an ID token).

This step is server-side because it is where trust is established — never expose the exchange or any secret to the browser.

Step 5 — Read the profile and create a session

Call the userinfo endpoint with the access token to read the user's profile claims. The key field is the stable profile identifier:

• Store the profile identifier as the link between the DeadArk user and your app's account record. This is how you recognize the same person next time.
• Use display claims (name, avatar) for presentation.
• Do not expect or store a private account UUID — it is not exposed.

Create your session and you are done. The returning user repeats the flow and matches on the same stable profile identifier.

Common pitfalls

• Redirect URI mismatch. It must match a registered value exactly, including scheme and path.
• Skipping `state` verification. Always verify it; it is your CSRF defense.
• Exchanging the code in the browser. Do the token exchange server-side.
• Storing the wrong identifier. Key your user records on the stable profile identifier, not on a display name or email.

The short version

Register a client, run the PKCE Authorization Code flow, verify state, exchange the code server-side, then store the stable profile identifier to recognize the user. See OAuth 2.1 and PKCE for Passkey-Backed Login for the security details.