Quick Start — add sign-in to your app

The Quick Start tab is the fastest path from "I just registered an app" to "users can sign in." Open it, pick your framework, and copy code that already knows your clientId and issuerUrl — no hunting through settings tabs.

Before you begin

• You have registered an application and are looking at its detail page.
• You know the framework your app is built in (React SPA, Node.js server-side, or plain HTTP/cURL).
• For server-side and M2M apps, you have a way to store secrets safely (environment variable, secrets manager).

Where the Quick Start lives

Open an application, go to the Credentials tab, then scroll to the Quick Start section. You'll see language sub-tabs — React, Node.js, cURL — and each one contains a snippet pre-filled with your application's actual clientId, issuerUrl, and the first redirect URI you registered.

The snippet is generated fresh on every page load. If you add a new redirect URI in Settings and come back here, the snippet will reflect it.

Screenshot pending /screenshots/admin.applications.quick_start/section.png

React SPA

Install the SDK, wrap your app in the provider, and you're done.

Example multi-language

App.tsx

import { IntelliAuthProvider, useIntelliAuth } from "@intelliauth/react";

const issuerUrl  = "https://uat-cymmetri.intelliauth.local";
const clientId   = "YOUR_CLIENT_ID";   // pre-filled in the Quick Start snippet
const redirectUri = "http://localhost:3000/callback";

function SignInButton() {
  const { user, login, logout, isLoading } = useIntelliAuth();

  if (isLoading) return <p>Loading…</p>;

  if (user) {
    return (
      <div>
        <p>Signed in as {user.email}</p>
        <button onClick={logout}>Sign out</button>
      </div>
    );
  }

  return <button onClick={login}>Sign in</button>;
}

export default function App() {
  return (
    <IntelliAuthProvider
      issuerUrl={issuerUrl}
      clientId={clientId}
      redirectUri={redirectUri}
    >
      <SignInButton />
    </IntelliAuthProvider>
  );
}

package.json

{
  "dependencies": {
    "@intelliauth/react": "latest"
  }
}

useIntelliAuth() returns { user, login, logout, isLoading }. Call login() to redirect the user to the hosted sign-in page. After the callback, user.email (and the rest of the OIDC profile) is available immediately.

SPAs have no client secret

SPA applications use PKCE and do not receive a client secret. If the Quick Start snippet shows a CLIENT_SECRET field for a SPA, the application type is mis-configured — check Settings → Application type and switch it to Single-page application.

Node.js (Express)

Server-side apps use the authorization-code flow. The client secret stays on your server — never in the browser.

Example multi-language

server.js

import express from "express";
import { IntelliAuthClient } from "@intelliauth/node";
import session from "express-session";

const app = express();

app.use(session({ secret: process.env.SESSION_SECRET, resave: false, saveUninitialized: false }));

const client = new IntelliAuthClient({
  issuerUrl:    process.env.ISSUER_URL,
  clientId:     process.env.CLIENT_ID,
  clientSecret: process.env.CLIENT_SECRET,  // server-side only — never sent to the browser
  redirectUri:  process.env.REDIRECT_URI,
});

// Step 1: redirect the user to the hosted sign-in page
app.get("/login", async (req, res) => {
  const { url, codeVerifier } = await client.authorizationUrl();
  req.session.codeVerifier = codeVerifier;
  res.redirect(url);
});

// Step 2: exchange the code, set the session
app.get("/callback", async (req, res) => {
  const tokens = await client.exchangeCode({
    code:         req.query.code,
    codeVerifier: req.session.codeVerifier,
  });
  req.session.user = tokens.idTokenClaims;
  res.redirect("/dashboard");
});

app.get("/dashboard", (req, res) => {
  if (!req.session.user) return res.redirect("/login");
  res.send(`Hello, ${req.session.user.email}`);
});

app.listen(3000);

package.json

{
  "dependencies": {
    "@intelliauth/node": "latest",
    "express": "^4.18.0",
    "express-session": "^1.17.0"
  }
}

.env

ISSUER_URL=https://uat-cymmetri.intelliauth.local
CLIENT_ID=YOUR_CLIENT_ID
CLIENT_SECRET=YOUR_CLIENT_SECRET
REDIRECT_URI=http://localhost:3000/callback
SESSION_SECRET=change-me-to-something-long-and-random

The CLIENT_SECRET you see in the Quick Start snippet is the same value shown in Credentials → Client secret. Treat it like a database password: keep it in a secrets manager or environment variable, never in source code.

cURL (testing and M2M)

Use cURL to confirm the flow works before writing application code, or to run client-credentials grants from backend jobs that have no user.

Example multi-language

Discover endpoints

# Fetch the discovery document — shows authorize, token, and JWKS URLs
curl -s https://uat-cymmetri.intelliauth.local/.well-known/openid-configuration | jq .

M2M token (client_credentials)

# Exchange client credentials for an access token — no user redirect involved
curl -s -X POST https://uat-cymmetri.intelliauth.local/oauth2/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET" \
  -d "audience=https://api.cymmetri.example" \
  | jq .

Authorization code exchange

# After the user was redirected back to your callback URL with ?code=AUTH_CODE
curl -s -X POST https://uat-cymmetri.intelliauth.local/oauth2/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET" \
  -d "code=AUTH_CODE" \
  -d "redirect_uri=http://localhost:3000/callback" \
  | jq .

M2M applications use client_credentials. There is no user redirect — your service posts its credentials and gets a token back directly.

Common gotchas

Redirect URI mismatch. The callback URL in your code must match an entry in Settings → Redirect URIs character-for-character. http://localhost:3000/callback and http://localhost:3000/callback/ are different entries. So are http and https. The platform rejects mismatches before the user even sees a form.

Client secret in a SPA. Single-page apps don't use a client secret. If your code includes one, the application type is misconfigured. Switch to Single-page application in Settings, and the Quick Start snippet will update to show a PKCE flow without a secret.

Client secret in source control. For server-side and M2M apps, the client secret belongs in an environment variable or a secrets manager, not in your repository. Rotate it immediately from Credentials → Client secret → Rotate if it leaks.

M2M with a redirect. M2M applications use the client_credentials grant — there is no user, so there is no redirect. If your M2M integration is trying to redirect users to a login page, the application type is probably set to Web instead of Machine-to-machine.

See also

• Credentials tab
• Applications overview