Muhajir Project
Request access
PROFILE PROVIDER

Hosted login for appsthat need secure access fast.

Register applications, enforce PKCE, collect consent, issue tokens, and expose scope-filtered user APIs without building auth from scratch.

Use hosted login and scope-filtered user APIs as one centralized profile provider where multiple applications request trusted user data from one source.

Authorization Code Flow
OIDC
S256 only
PKCE
profile, email, permissions
Scopes
/api/external/me
API
Read the docsRequest access
  • No client secret
  • Hosted consent
  • Admin-managed apps
Authorize requestS256
client_id
app_8f3a2b
response_type
code
scope
openid profile email
redirect_uri
/auth/callback
Profile Provider response
{
  "sub": "user_123",
  "email": "user@example.com",
  "emailVerified": true,
  "name": "Jane Developer"
}
Capabilities

Everything your integration needs to sign users in safely.

The login provider combines admin-managed application setup with hosted user flows and scope-aware APIs.

  • Public PKCE clients

    Applications receive a public client ID and use Authorization Code Flow with PKCE. No client secret is issued for browser or mobile-style clients.

    code_challenge_method=S256

  • Exact redirect control

    Admins register allowed origins and redirect paths so authorization callbacks are constrained to known application URLs.

    origin + redirect path = valid redirect URI

  • Hosted login and verification

    Users sign in, sign up, and verify their email in the hosted login experience before authorization completes.

    email verification before authorization completion

  • Consent with app metadata

    Consent screens can show registered application details such as app name, logo, description, and requested scopes.

    public application metadata

  • Scope-filtered user API

    Applications call /api/external/me with a bearer access token and receive only the fields allowed by granted scopes.

    openid required

  • Browser-ready CORS

    Registered browser origins can call the token endpoint and external APIs with non-credentialed bearer-token requests.

    Authorization: Bearer ACCESS_TOKEN

  • Centralized profile provider

    Multiple applications request shared profile data through scopes instead of collecting the same user data repeatedly.

    cross-application profile data
Profile Provider layer

One profile provider for every app your users trust.

The Profile Provider centralizes sign-in, consent, and scope-filtered user APIs for multiple applications: one user profile, one trusted identity source, and one place to request the data each app is allowed to access.

Why it matters
  • Users do not re-enter the same profile data for every application.
  • Teams avoid rebuilding user profile storage for every new app.
  • Admins manage application access from one place.
  • Scopes define which profile and data categories each app can access.
How it works

From registration to user profile in five steps.

  1. 01

    Register the application

    Create an app in the admin dashboard with origins, redirect paths, scopes, display metadata, and optional logo.

  2. 02

    Redirect to hosted login

    Send the user to the authorization endpoint with PKCE, state, nonce, redirect URI, and requested scopes.

  3. 03

    Verify and consent

    The hosted experience handles login, signup, email verification, and consent using the registered app metadata.

  4. 04

    Exchange the code

    Your app exchanges the authorization code using the original PKCE verifier. Public PKCE clients do not send a client secret.

  5. 05

    Call the external API

    Use the access token to fetch the scope-filtered user profile from /api/external/me.

A complete login flow your users can trust.

Illustrative preview

Show users a familiar hosted login experience, collect consent clearly, and give developers a predictable API response after login.

Hosted login
user@example.com
••••••••••
Continue

Users authenticate in a hosted flow before your app receives an authorization code.

Consent

Acme Reports wants access to your account

  • profile
  • email
  • permissions

Consent is tied to registered application metadata and selected scopes.

Admin config
client_id
app_8f3a2b
origin
https://app.example.com
redirect path
/auth/callback
scopes
openid profile email

Admins control origins, callbacks, scopes, and metadata every integration can use.

Shared profile source
  • verified email
  • display name
  • avatar
  • permissions
{
  "sub": "user_123",
  "email": "user@example.com",
  "emailVerified": true,
  "name": "Jane Developer"
}

The response only includes fields granted by the access token's scopes.

Integration paths

Built for common application shapes.

  • React SPA

    Use browser PKCE, registered origins, and bearer-token calls to external APIs.

    Read SPA recipe

  • Node.js backend

    Keep tokens server-side while giving the browser only your application session.

    Read backend recipe

  • Mobile app

    Use PKCE with HTTPS Universal Links or Android App Links for redirect handling.

    Read mobile recipe
Request access

Want to try it with your application?

Request access and include the application details your admin needs to register the client: company, origin, redirect path, scopes, and use case.

Request access
Start here

Start with the docs, or request access for your first registered app.

The provider is ready for technical teams who need a secure hosted login, consent, and profile API path without building the platform from scratch.

Read the docsRequest access
FAQ

Questions teams ask before integrating.

Clear answers about Public PKCE clients, scopes, browser API calls, and how profile data is shared across applications.

Do applications need a client secret?

No. Admin-created applications are Public PKCE clients and do not receive a client secret.