Add the national sign-in in an afternoon.

It looks like yours, because it is yours

The maker of this prototype, Sambit Swarup, chose the design language your portal already runs over a custom look. So the button, the consent screen and the account are your own contracts with six classes added, built from your own tokens. Your citizens see the chrome they already trust; your team pastes markup instead of running a redesign; accessibility comes with it.

Quickstart — six steps to “Meri Pehchaan Ready”

1. Register your service. Name, logo, redirect URIs, back-channel logout URI, and the scopes you will ask for. That name and logo are what the citizen sees on the consent screen — they are the contract.
2. Get sandbox keys. A client id and secret that work only against this sandbox. Nothing here touches a live system.
3. Drop the button in. First in your form's action area, alone, full width. Your existing form goes under “Other ways to sign in” — collapsed, never removed.
4. Point your callback at the hub. Standard authorization-code + PKCE. Verify the id_token against the published JWKS. Read acr.
5. Declare assurance per action. Viewing is Shabda, filing is Anumaan, signing is Pratyaksh. Ask for step-up in place; never send the citizen away.
6. Pass conformance, go live. The checklist at the bottom of this page is the badge. The sandbox faults are the exam.

The button kit

Verb only, one language at a time, the Pehchaan Chakra on the left. Twelve languages switch with the page. Never “Login with”, never “Powered by”, never a provider's name on it.

<button class="ux4g-btn-meripehchaan ux4g-btn-lg ux4g-w-100" type="button" data-action="portal-signin">
  <svg class="ux4g-btn-icon" aria-hidden="true"><use href="/design/mark/pehchaan-chakra.svg#mark"/></svg>
  <span data-verb="signin" lang="en">Sign in</span>
</button>

The OpenID Connect contract — read live from the hub

This table is not typed in. It is /.well-known/openid-configuration, fetched by this page when you opened it.

// Node (Hono) — the callback your portal already has, pointed at the hub
const tokens = await fetch(discovery.token_endpoint, { method: "POST",
  body: new URLSearchParams({ grant_type: "authorization_code", code, redirect_uri,
    client_id, client_secret, code_verifier }) }).then(r => r.json());
const { payload } = await jwtVerify(tokens.id_token, JWKS, { issuer, audience: client_id });
// payload.acr → "mp:shabda" | "mp:anumaan" | "mp:pratyaksh"; payload.mp_adhikrit → roles
session.create({ sub: payload.sub, name: payload.name, acr: payload.acr, sid: payload.sid });

• Authorization code with PKCE (S256) is mandatory; codes are single-use and live 60 seconds.
• Refresh tokens rotate. Token exchange (RFC 8693) carries a delegated act claim for helpers acting under a grant.
• Revocation (RFC 7009), introspection (RFC 7662) and back-channel logout are all live in this sandbox.
• Wire paths mirror the published DigiLocker partner API (/public/oauth2/1/authorize, /public/oauth2/2/token, /public/oauth2/1/user) so an existing integration changes one hostname.
• Page translation is mapped to Bhashini, the national language platform, through its published pipeline API (config, then compute, translation task) under the department's own key. Twelve languages ship as page strings; the rail is switched off in this sandbox and nothing here calls the live service.

Assurance per action

Send acr_values for what the action needs, not for what the portal wants in general. The hub steps up in place; the citizen never leaves your page.

The request parameters, by their published names

Meri Pehchaan 1.0's Requester specification v2.3 (September 2023, on API Setu) already defines these. The hub honours every one under the same name, so a portal integrated with 1.0 sends what it sends today. Live rail

What 2.0 adds to the token, and 1.0 does not carry: acr, amr, sid, nonce, auth_time; discovery and JWKS; back-channel logout. Proposed

Every consent receipt is written in the API Setu consent-artefact schema (consentId, dataConsumer, dataProvider, purpose, user, data, permission, signature) and every NSSO Consent API operation has an alias under its published name. Spec files are public at cf-media.api-setu.in/specfiles/. Live rail

Sandbox — break it before a citizen does

These switches change the live hub behind this site. Turn one on, then walk the sign-in. hub_down is the exam: your portal must show its own login and keep every open session.

• hub_down — discovery, JWKS and authorize answer 503; portal sessions keep serving
• idp_down — the routed identity provider is unavailable; the hub offers another identifier
• otp_delay — the OTP gateway is slow; the resend timer earns its keep
• otp_peak — the gateway is at capacity (429 with retry-after)
• dup_account — two accounts match the identifier; the citizen chooses
• clock_skew — the hub's clock is off; token validation must tolerate it

Hub status as your portal sees it: checking…

Three ways to join, matched to how your portal is run

“Meri Pehchaan Ready” — the checklist behind the badge

• checkThe button is first, alone and full width; the department's own login is one tap away, never removed
• checkConsent is shown by the hub before the redirect; the portal asks only for scopes it registered
• checkacr is read on every callback and every step-up; signing actions demand Pratyaksh
• checkWith hub_down on, the portal still signs in the old way and no open session is lost
• checkBack-channel logout ends the portal session within 30 seconds of “Sign out everywhere”
• checkActions taken under a grant are logged as “helper, for citizen, under grant”

A concept badge, awarded by nobody. The list is the point; the reference architecture, adapter tiers and migration waves are in the repository's docs/03.