Sign in With DeadArk: OAuth, OIDC, and PKCE

What it is

Sign in with DeadArk lets your application authenticate users through DeadArk using standard, boring, well-understood protocols: OAuth 2.1 for authorization and OpenID Connect (OIDC) for identity, with PKCE protecting the flow. There is no proprietary handshake to reverse-engineer and no lock-in SDK you are forced to adopt — if your stack already speaks OAuth and OIDC, it already speaks Sign in with DeadArk.

The value proposition for an integrator is simple: you stop owning passwords. DeadArk handles authentication — passkey-backed and phishing-resistant — and hands your app a verified identity.

Why it is worth integrating

• Passkey-backed security, for free. Because DeadArk is passkey-first, every Sign in with DeadArk user authenticates with a device-bound credential. Your app inherits that security without building any of it.
• No password liability. You never store, reset, or breach a password you never held.
• Portable identity. Users arrive as a stable, portable profile — the same identity they carry across other apps — rather than yet another isolated account.
• Standards, not lock-in. OAuth 2.1 + OIDC + PKCE means your integration is portable knowledge, not a bespoke dependency.

The shape of the flow

At a high level, Sign in with DeadArk is the textbook Authorization Code flow with PKCE:

• Your app redirects the user to DeadArk's authorization endpoint with your client_id, redirect_uri, requested scope, state, and a PKCE code_challenge.
• The user authenticates with their passkey and approves the requested scopes.
• DeadArk redirects back to your redirect_uri with an authorization code.
• Your server exchanges the code (plus the PKCE code_verifier) for tokens.
• Your app calls the userinfo endpoint to read the user's profile claims.

If you have implemented "Sign in with" anything before, this is the same flow.

What your app receives

The identity you get back is deliberately scoped:

• A stable profile identifier that represents the user consistently across sessions and apps — this is what you store to recognize a returning user.
• Public profile claims appropriate to the scopes you requested (such as display name and avatar).
• Never the private account UUID. A user's underlying account identifier is not exposed to integrating apps. You identify users by their portable profile identity, which is the right boundary: enough to recognize them, never enough to compromise them.

Where to go next

This is the conceptual overview. For the step-by-step setup, see How to Add Sign in With DeadArk; for the security mechanics, see OAuth 2.1 and PKCE for Passkey-Backed Login; and for the identity model itself, see How Portable Profile IDs Work.

The short version

Sign in with DeadArk is standard OAuth 2.1 + OIDC with PKCE, backed by passkeys, returning a stable portable profile identity — so your app gets secure login and a real user identity without owning passwords.