Identity and access management is the discipline of making sure the right people and workloads have the right access to the right resources at the right time — and that you can prove it. It spans four moving parts: identities (who or what is acting), authentication (proving that identity), authorization (deciding what it may do), and governance (reviewing and evidencing all of the above). Every Identity Bytes track is one slice of this picture.

Authentication answers who are you — proving an identity with a password, a passkey, a certificate or a token. Authorization answers what are you allowed to do — evaluating policy to permit or deny an action on a resource. A common failure is treating a successful login as permission to do anything; strong systems authenticate once and then authorize every sensitive action separately.

The identity lifecycle is the set of events an account goes through: a joiner is created and given birthright access, a mover changes role and should gain and lose entitlements accordingly, and a leaver is disabled and de-provisioned. Most real-world risk hides in movers who accumulate access and leavers who are never disabled. Automating this lifecycle is the heart of identity governance.

Least privilege means every identity should hold only the permissions it needs to do its job, and no more, for no longer than necessary. It limits the blast radius when an account is compromised. In practice it drives design choices like scoped API permissions, just-in-time role activation instead of standing admin rights, and time-boxed access that expires automatically.

RBAC (role-based access control) assigns permissions to roles and roles to users — simple to reason about but prone to role explosion as edge cases multiply. ABAC (attribute-based access control) evaluates attributes of the subject, resource, action and environment at decision time, allowing fine-grained, context-aware policy without a role for every combination. Mature programmes often use RBAC for coarse structure and ABAC for the nuanced decisions.

A directory (such as Active Directory or an LDAP server) is the authoritative store of identity objects — users, groups and their attributes. An identity provider (IdP) is the service that authenticates those identities and issues tokens or assertions to applications. Entra ID is both a directory and an IdP; OpenLDAP is a directory that you pair with an IdP like Keycloak.

Zero trust replaces implicit network trust with continuous, identity-centric verification: never trust, always verify. Identity becomes the primary control plane, so every request is authenticated, authorized against policy, and evaluated for risk signals like device posture and location. IAM is the foundation zero trust is built on — you cannot verify what you cannot identify.

Start with the vocabulary and a reference architecture before touching any product, which is exactly what this track does. Then move to the Entra ID Security track to apply the concepts against a real identity provider and produce audit evidence. Learning the pattern first, then the product, means your skills transfer when the tooling changes.