How B2B authentication works

This describes the building blocks for implementing business-to-business (B2B) authentication scenarios.

Organizations

An organization represents your business customers or partners. For example, an organization may represent a store that uses your online banking platform to manage their finances, or a restaurant that uses your food delivery service.

Organizations are created on the tenant-level and can be provided access to one or more applications. You can manage organizations via API or the Admin Portal. Transmit also offers a dedicated self-service portal that allows organization admins to manage their own memberships.

Members

Members represent the organization's customers or employees. For example, consider an airline website that allows travel agents to login to book flights on behalf of users. In this case, the travel agent is a member of a travel agency organization.

Members can be created in several ways:

• Added to an organization directly
• Invited to join using an email invitation
• Created automatically upon their first SSO login

Members are Transmit users with memberships to the organization, and are identified by their user_id. As such, a user can have memberships to multiple organizations and creating a member doesn't necessarily mean that a new user is created. If the app also provides B2C services, a user may also have a personal account that is outside the context of an organization.

Authentication

An application can authenticate members in several ways. They can use a Transmit login method (like WebAuthn biometrics, email magic link, password, etc.), which can be integrated directly into the application or implemented using the Transmit hosted experience. An application can also allow organizations to login members by SSO using their own OIDC or SAML identity providers.

Role-based access

An organization can control access to the application based on the member's roles in the organization, also known as role-based access control (RBAC).

You can define roles that are relevant for your application, and decide which permissions are provided by each role. For example, an airline website may provide different permissions to end-users vs travel agents that book on behalf of users. The role will determine the level of access that will be provided by the member that logs in. The roles of a member can be fetched directly, or returned in the ID token upon successful authentication.

Although an organization is responsible for assigning roles to its members, the application can control which roles they can assign using role groups. The application creates a role group with a specific set of roles, and then assigns the relevant role groups to the organization. The organization can only assign roles to a members if the role is included in the role groups of that organization.