MAGNEXIS IDENTITY / EARLY DEVELOPMENT

An identity for
what comes next.

Sign in with Magnexis is a developing OpenID Connect identity provider and integration SDK. Designed for secure sign-in flows across Magnexis applications and, following launch, third-party sites.

01 / The authentication flow

Simple for users.
Standards-based for developers.

No shared passwords between sites: users authenticate with the identity provider and return via a protected authorization flow.

Your websiteOIDC client
Magnexis IdentityAuthenticate + consent
Your callbackCode + PKCE
01 / REGISTER

Register a client

Define a unique client ID, exact redirect URLs, and approved origins with the identity provider administrator.

02 / REDIRECT

Start authorization

Use the Authorization Code flow with PKCE (S256), state validation, and OIDC discovery.

03 / VERIFY

Establish a session

Validate returned identity through the SDK or a server-side OIDC library before trusting user data.

02 / Integration

A recognizable button.
Underneath, real standards.

JAVASCRIPT
import { MagnexisAuth } from '@magnexis/identity';

const mx = new MagnexisAuth({
  issuer: 'https://AUTH_HOST/realms/magnexis',
  clientId: 'your-client-id',
  redirectUri: `${window.location.origin}/callback`,
});

button.addEventListener('click', () => mx.signIn());
// On /callback: await mx.handleCallback();
BRANDED AUTHENTICATION / PREVIEW

Continue with Magnexis.

Integrate a familiar sign-in choice with a clearly documented provider boundary.

Continue with MagnexisVisual component — not connected to production accounts.
◈
Not publicly available yet. This release includes a local Keycloak realm and browser SDK prototype. A secure HTTPS identity hostname, persistent service, email verification, operational security, and a client onboarding process must be finished before real users can sign in.
IDENTITY PLATFORM / DELIVERY STAGES

A clear path from local proof to public service.

The branded sign-in journey is being prepared as a standards-based developer platform. The identity service is not advertised as generally available.

LOCAL

Prototype integration

Run the local provider and example app, register a development client, and inspect the browser redirect flow. No real accounts or sensitive personal data are required for this demonstration.

HARDEN

Production prerequisites

A public service requires HTTPS, durable storage, monitored infrastructure, mail verification, recovery controls, secrets rotation, rate limits, and an explicit incident response process.

RELEASE

Developer enrollment

Client onboarding must include verified ownership, restricted redirect URIs, documented scopes, a privacy policy, and a supported contact path before external websites rely on sign-in.