OCI Identity Domains Explained

Identity is the foundation of cloud security, because every access decision rests on knowing who is asking. On OCI, identity is organised through identity domains, the place where your users, groups and the way they authenticate all live. Understanding what a domain is and how to use it is the starting point for everything else in security, because policies, network rules and data controls all assume that identity underneath them is sound.

The problem teams run into is treating identity as an afterthought, a set of accounts created as needed without a plan, which produces an estate where nobody can say with confidence who has access to what. That uncertainty is itself a security weakness. A clear identity design, organised through domains, replaces it with a structure you can reason about, which is the precondition for least privilege.

What an identity domain is

An identity domain is a container for identity. It holds the users who can authenticate, the groups they belong to, and the settings that govern how they prove who they are, such as the password rules and the multi factor authentication requirements. When an application or a person authenticates to OCI, they do so within a domain, and the domain is what manages that authentication and the identities behind it. Think of it as the directory and the authentication policy bundled into one managed thing.

Domains let you organise identity along boundaries that matter to you, separating, for example, the identities for one part of the organisation from another, or one environment from another, each with its own settings. This structure is what turns a flat list of accounts into something you can govern, because access and policy can be reasoned about within the clean boundaries a domain provides rather than across an undifferentiated pool of users.

Users, groups and why groups matter

Within a domain you have users, the individual identities, and groups, the collections of users that access is actually granted to. The discipline that matters here is to grant access to groups rather than to individual users. When access is attached to a group, you manage access by managing group membership, which is far easier to reason about and to keep correct than a web of individual grants. A new joiner is added to the right groups and immediately has the right access, and a leaver is removed from groups and immediately loses it.

This is not merely tidy, it is a security control. Access granted to individuals scatters across the estate and becomes impossible to audit, while access granted to groups concentrates in a structure you can review. When you write the policies that grant access, covered in our IAM policies guide, you grant to groups, and the group design and the policy design support each other. A clean group structure is half the battle in keeping access least privilege.

Authentication and federation

Domains also govern how identities authenticate, and this is where you enforce the strength that protects the foundation. Multi factor authentication should be the default for human access, because passwords alone are not enough for anything that matters, and the domain is where you require it. For privileged identities that can change the estate, strong authentication is not optional.

Many organisations already have a central identity provider where employees are managed, and federating OCI identity with that provider is the pattern that scales. Federation means people authenticate through the central provider, so joiners and leavers are handled in one place rather than separately in OCI, which closes the common gap where someone leaves the organisation but their cloud access lingers. Federating identity is covered further in this cluster, and it is the right approach for any organisation of size.

How domains support the wider security model

The reason to get domains right is that everything above them assumes they are sound. The policies that express least privilege grant access to the groups in your domains. The network and data controls protect resources that those identities reach. If the identity layer is murky, with unclear groups and lingering accounts, then the careful work in the layers above rests on sand. This is why the complete security guide treats identity as the foundation and everything else as built on top.

A framework for clean identity

Keeping identity current over time

An identity foundation is only sound while it reflects reality, and reality changes constantly as people join, move roles, and leave. The most common identity weakness is not a bad initial design but a good design left to drift, with accounts for people who have gone, group memberships that no longer match anyone's actual job, and access granted for a project that ended long ago. Each of these is a small risk on its own and a serious one in aggregate, because they accumulate into an estate where the access that exists no longer matches the access that should.

The discipline that prevents this is regular review and, where possible, automation through federation so that the central source of truth about who works here drives what they can reach. When joiners and leavers flow from one place, the cloud identity stays current without a separate manual effort, and the gap where a departed employee keeps access simply does not open. Treating identity as something to maintain rather than set is what keeps the foundation sound year after year.

Bringing it together

Identity domains are where the security of an OCI estate begins, because they hold the users, groups and authentication that every other control depends on. Organise domains along meaningful boundaries, grant access to groups rather than individuals, enforce strong authentication, and federate with your central identity provider so the set of identities stays current. Done well, this gives you an identity foundation you can reason about, which is exactly what least privilege requires. The next step is expressing access cleanly, covered in our IAM policies guide, and the whole picture sits in the complete security guide. Our IAM and security solution helps you design the identity foundation from the start.