Acting on behalf of a company is one of the hardest identity problems in digital services. The question is not only who the user is, but also on whose behalf they are acting and under what authority. This article looks at B2B authorizations through a CIAM architecture lens: how an authorization is created, where it is managed, and how it is ultimately conveyed to services.
Acting on behalf of a company in digital services
When a person uses a digital service in their own name, the identity logic is straightforward: the user is authenticated and the service knows who is signed in. The user is linked to a contract either through a payment event or through a national identity number.
In B2B services, the situation changes fundamentally. Very few people use a service entirely in their own name. Instead, they act on behalf of an organization: as an employee, a consultant, a representative of a service provider such as an accounting firm, or someone with formal signing authority for the company.
That makes identity multi-layered: the service must know who the person is, which organization they represent, and under what authority they act. This is where many CIAM implementations begin to crack. Authorization becomes an order of magnitude more complex, and the consumer-style identity model is no longer enough.
To keep the whole picture manageable, it helps to look at B2B authorizations as if they were an anatomy lesson: break the whole into parts and understand how authorizations are created, where they are managed, and what role CIAM actually plays.
The anatomy of the authorization chain
In B2B services, authorization is rarely simple. It often takes the form of a chain in which authority is passed through multiple parties.
Typical scenarios include:
- Company → employee
A company gives an employee the right to use a service on the company's behalf. This is the most common case in banking, insurance, and public-sector services. - Company → external person
A company may also authorize someone outside the organization, such as an accountant, lawyer, or consultant. In that case, the authority does not rest on employment but on a separate agreement, such as a power of attorney. - Company → another company → employee
A more complex, but very common, chain emerges when one company authorizes another company to handle matters on its behalf. The service is then ultimately used by an employee of that second company.
In practice, this means the system often has to understand both the individual and their organizational context. A user account alone is no longer remotely sufficient to describe the real authorization situation.
Where CIAM's responsibility begins and ends
One of the central design questions in any CIAM solution is what CIAM should actually do, and what it should not.
Typically, CIAM is responsible for:
- authenticating the user reliably
- linking the user to the correct organization
- passing the application the user's role or authority context
- producing an auditable trail of who acted and on whose behalf
CIAM is usually not the right place to decide things such as:
- whether a power of attorney is legally valid
- who inside an organization is allowed to grant authority
- which contract or legal basis gave rise to that authority
Those belong to organizational processes and legal governance, not to the identity system itself.
When that boundary becomes blurred, CIAM too easily turns into a system that tries to solve business and legal problems as well. Usually with a poor outcome.
Powers of attorney: legal authority outside CIAM
Acting on behalf of a company is almost always based on some legal mechanism.
That mechanism may be, for example:
- a power of attorney
- a contract-based authorization
- internal authority or signing rights within the organization
- a right based on a public register or authority registry
In many organizations, these are still managed manually: a power of attorney is delivered to the service provider, and user rights are then granted in the system on that basis.
In some cases, inter-organizational authorizations, in other words powers of attorney, have been digitized into a separate service that meets legal requirements and acts as the source of authorization data.
A CIAM solution can manage user roles and access rights within the service. Legal authorization, however, such as powers of attorney or the right to represent someone, typically originates outside CIAM. CIAM uses that authorization data as part of the identity context and passes it to downstream applications.
What about Suomi.fi authorizations?
In Finland, the best-known digital authorization solution is Suomi.fi authorizations, which is widely used in public services. It provides a centralized way to manage authorizations in situations where a person is acting on behalf of a company or another individual.
In this model:
- the organization grants authority in a centralized service
- the user is strongly authenticated
- the service checks via an API whether the user is authorized to act on the organization's behalf
Architecturally, the model clearly separates three concerns: authentication, authorization management, and service usage.
In the private sector, however, Suomi.fi strong authentication is not available in quite the same way as it is for public services. Instead, a service may authenticate the user through bank credentials via the Finnish trust network and use the personal identity code to ask the Suomi.fi authorizations API whether the individual has the right to act on behalf of a company or another person.
Suomi.fi authorizations are an interesting option for the digital management of powers of attorney in the private sector as well, but it is hard to see them as a universal solution for every scenario. Authorizations are tied to Suomi.fi authorization matters and codes, which means the service must adapt its own authorization model to a predefined structure.
That is why many B2B services still need other ways to manage authorizations. Even so, Suomi.fi is a good architectural example of a model where legal authority, authentication, and service usage are kept separate.
How authorizations appear in a CIAM architecture
When a user signs in, the application ultimately needs a centralized answer to the question of under what authority the user is acting. This is where CIAM often serves as the system's central source of authorization context.
Authorizations may still originate from several different sources, for example:
- authorizations based on powers of attorney
- rights granted through delegated administration
- rights based on an organization's internal user management
- rights coming from another organization's identity system through federation
The role of CIAM is to combine these sources into a single view and pass that view to the services at sign-in.
From the application's perspective, the critical questions are usually:
- who the user is
- which organization they represent
- which role or authority they are acting under
After that, the application itself makes the final decision about what the user is allowed to do.
Architecturally, this means that even if authorizations are created in several places, CIAM acts as their centralized broker and trusted source for the services.
This helps keep three concepts apart that are often conflated: identity - who the user is; authority - on whose behalf the user acts; access rights - what the user is allowed to do in the service.
Summary
B2B authorizations are one of the most demanding areas in CIAM architecture because identity no longer means just the user. The service has to understand an entire context: who the user is, which organization they represent, and under what authority they act.
The core architectural principle is that legal authority is usually created outside CIAM, for example through powers of attorney, contracts, or internal models of representation and authority. CIAM's role is to authenticate the user, combine authorization data coming from different sources, and pass it to services as a coherent authorization context.
When that division of responsibilities is kept clear, the identity architecture for B2B services remains manageable as well.
Need a clear B2B authorization model?
In 30 minutes, we can review how your B2B authorizations and CIAM architecture currently work: where authority is created, how it flows into your systems, and what should be fixed first. You will get a concrete recommendation for the next steps, with no commitment required.
