Admin Portal
What is the Admin Portal
The AdminPortal (React) / adminPortal (JS) composite component is a drop-in, embeddable B2B admin console. You add it to your application, and the organization administrators among your customers use it to run their own organization without involving your team. From a single place, they can manage members and invitations, define roles and permissions, set up SSO connections and SCIM directory sync, verify domains, edit organization settings, and configure security policies.
The Admin Portal is a UI layer over the Partner IAM APIs. Every action a user takes in the portal maps to a Partner IAM API call, authorized by the user's organization-scoped access token. The portal does not introduce any authorization of its own. It only renders, requests, and reflects what the APIs allow for the current token.
You can consume it in two ways:
- Full composite: render the complete
AdminPortalcomponent to get the entire organization administration experience out of the box. - Individual widgets: render organization widgets (such as
OrganizationUsers,OrganizationRoles,OrganizationConnections,OrganizationSCIM,OrganizationSettings,OrganizationDomainManagement,OrganizationDangerZone,OrganizationSelector, andOrganizationSwitcher) on their own to build a custom layout.
For the full widget catalog and per-component API reference, see the SDK component documentation:
How authentication works
The Admin Portal authenticates users through the OAuth 2.0 / OpenID Connect (OIDC) Authorization Code flow, using PKCE for public clients such as SPAs and mobile apps. A user's access to an organization comes from the role an admin assigns them in it. When the user signs in, LoginRadius adds that organization's context to the issued access token as claims, and the portal acts on those claims. The flow below is conceptual and follows the standard OAuth 2.0 / OIDC Authorization Code with PKCE flow.
- Assign the user a role in the organization. An admin invites the user to the organization with a role. The role is either one of the default
lr:*roles or a custom role built from the default permissions (both are described later in this section). - User signs in. The user opens the application embedding the Admin Portal, which starts the Authorization Code flow and redirects the user to the authorization endpoint (LoginRadius, or the configured IdP).
- LoginRadius issues a token with organization claims. After successful authentication (and any required consent or MFA), LoginRadius issues an access token (plus an ID token for OIDC). Based on the user's assigned role in the active organization, the backend adds the organization context to the access token in a custom
org_ctxclaim. All downstream organization-authorization decisions are based on these claims.
Organization claims
The org_ctx claim is the token contract the portal reads to decide which controls to enable, disable, or hide.
| Claim | Type | Description |
|---|---|---|
org_ctx | object | Organization context attached to the access token |
org_ctx.org | string | Organization identifier the token is scoped to |
org_ctx.roles | string[] (optional) | Role IDs the user holds in that organization |
org_ctx.permissions | string[] (optional) | Effective lr:* permissions for the user in that org |
The Admin Portal reads org_ctx.permissions to automatically enable, disable, or hide controls, so a user only sees the actions their permissions allow. The available actions therefore depend on the user's role in the active organization.
Switching organizations
An org-scoped token comes from the role a user holds in an organization, so there is no separate request to obtain one. To switch the active organization, the portal reuses the user's current refresh token and exchanges it for a new access token, sending the target organization's org_id along with the refresh_token grant. LoginRadius rebuilds the org_ctx claim for the organization named in org_id and returns a fresh token, so the user can move between the organizations they belong to without signing in again. The OrganizationSwitcher and OrganizationSelector widgets use this exchange internally.
Granting access with LoginRadius default roles & permissions
The authorization model has three building blocks:
- A permission is a fine-grained capability (for example,
lr:read:orgs). - A role bundles permissions.
- Roles are assigned to users within the context of an organization. The same user can have different roles, or none at all, in different organizations.
Default roles
Every B2B tenant is preconfigured with these roles:
| Role | Access | Permissions |
|---|---|---|
lr:org_admin | Full administrator access for org-scoped flows | All default permissions (see the catalog below) |
lr:users_admin | Manage org members, invitations, and org-level roles | lr:read:orgs, lr:read:user_roles, lr:write:user_roles, lr:delete:user_roles, lr:read:invitations, lr:write:invitations, lr:delete:invitations, lr:read:roles |
lr:org_viewer | Read-only access to organization data | lr:read:orgs, lr:read:org_connections, lr:read:roles, lr:read:user_roles, lr:read:invitations, lr:read:org_directories |
lr:sso_admin | Manage SSO / organization connections | lr:read:org_connections, lr:write:org_connections, lr:delete:org_connections, lr:read:orgs, lr:write:orgs |
Default permission catalog
These permissions are the building blocks for roles.
| Group | Permissions | Enables |
|---|---|---|
| Organization management | lr:read:orgs, lr:write:orgs | View org metadata; manage org policies & settings |
| Organization connections | lr:read:org_connections, lr:write:org_connections, lr:delete:org_connections | View / manage / delete org identity providers (SSO) |
| Role management | lr:read:roles, lr:write:roles, lr:delete:roles | View / manage / delete tenant roles |
| User role assignments | lr:read:user_roles, lr:write:user_roles, lr:delete:user_roles | View / modify / remove user-role assignments |
| Invitations | lr:read:invitations, lr:write:invitations, lr:delete:invitations | View / create-update / delete org invitations |
| SCIM (directories) | lr:read:org_directories, lr:write:org_directories, lr:delete:org_directories | View / manage / delete SCIM directories & tokens |
Default roles and permissions cannot be modified or deleted. Admins also cannot create roles or permissions using the reserved lr: prefix, which belongs to LoginRadius.
Creating custom roles from default permissions
Beyond the default lr:* roles, you can build custom roles from the default permission catalog. There are two ways to do this, depending on the scope you need.
Tenant-level roles
A LoginRadius tenant user creates these in the Admin Console, and they are available across every organization in the tenant. Use them for roles you want to reuse everywhere. For the steps, see Roles and Permissions and Configuring roles in an organization.
Organization-level roles
The OrganizationRoles widget in the Admin Portal creates roles scoped to a single organization, so they are visible and assignable only within that organization. Creating or editing them requires the roles.write permission (lr:write:roles), so only users whose role grants it see the create and edit controls. To create one, open the roles UI (the OrganizationRoles widget) and add or edit a role with a name, a description, and the permissions selected from the multi-select.
Assigning a role to a user
Roles take effect once you assign them to a user within an organization:
- Open the organization's members (the
OrganizationUserswidget) and select the user. - Assign one or more roles. The picker lists the tenant-level roles together with that organization's custom roles.
- On the user's next sign-in, the issued token's
org_ctx.rolesandorg_ctx.permissionsreflect the assignment, and the portal and APIs enforce them.
Custom roles and permissions cannot use the reserved lr: prefix, which belongs to LoginRadius.
Permissions are shared across the whole tenant. Tenant-level roles are available in every organization, while roles created with OrganizationRoles apply only to the organization where they were created.