An employee opens a business application, clicks Sign In, and starts working.
That looks like one simple action.
But behind it, an organization needs to answer several questions:
- Is this the right person?
- Are they allowed into this application?
- What can they do after signing in?
- What happens when they change jobs or leave?
Those are Identity and Access Management (IAM) problems. And solving them is a real IT specialty.
If you've supported account or login issues, you may have seen part of this work without seeing the whole system.
A successful login doesn't mean access is correct
Imagine a fictional support employee named Alex.
Alex needs to read customer support cases. Alex shouldn't automatically be able to change billing settings or create administrator accounts.
Now imagine Alex signs in successfully.
Authentication helps establish Alex's identity. Authorization determines which actions Alex is permitted to take.
Those are separate decisions. A person can authenticate successfully and still be denied access to a particular resource—and sometimes denial is the correct result.
A useful IAM professional understands both what the business wants and how the technology enforces it.
Different systems and teams own different parts of the decision
A simplified sign-in flow might involve:
Employee → Business application → Identity provider → Business application
The exact steps depend on the integration, but the distinction helps:
- An identity provider handles identity and authentication functions.
- The application may manage its own roles or permissions.
- A business owner determines who should be allowed to perform certain work.
- An identity or IT team may configure the account, integration, or access assignment.
In an OpenID Connect integration, for example, identity information can be conveyed using ID tokens. Microsoft's OIDC documentation explains that flow.
Not every application behaves identically, and an identity token alone doesn't mean every application permission has been granted.
The business requirement still matters: what should Alex actually be able to do?
Troubleshooting an employee login is more than resetting a password
Suppose Alex can open email but receives an access-denied message in the support application.
Instead of immediately resetting credentials, investigate:
- Did authentication succeed?
- Is the application assigned to this user?
- Is the necessary application role present?
- Is a conditional access rule or other policy blocking the session?
- What do the relevant logs or error messages show?
Some checks may belong to different teams. The goal is to gather evidence through systems you're authorized to use and route the issue correctly.
This is where identity work can become interesting to someone who already enjoys troubleshooting.
The job continues when an employee changes roles
Now imagine Alex transfers to finance.
Support-app permissions may no longer be appropriate. Finance access might need approval. The company should be able to explain what was changed and why.
When Alex leaves, someone has to address accounts, permissions, application assignments, and relevant sessions.
Disabling one directory account isn't proof that every existing session or application entitlement has disappeared.
That ongoing responsibility is one reason IAM includes more than provisioning new accounts.
Build a simple IAM lab around this scenario
You can demonstrate these ideas without building a full company network.
Create two fictional users and a resource. Decide which user should have access and document the expected result.
Test both. Record the successful and denied attempts.
If you want to explore sign-in integration, use a supported test application and identity provider. If you want to explore lifecycle management, change the fictional employee's role and verify the required access changes.
A strong portfolio page explains:
- The business problem: Who needed access to what?
- The configuration: How was the decision represented?
- The test: What succeeded and what was denied?
- The limitation: What would require more work in production?
The Six-Figure IAM Career Playbook helps IT professionals choose an IAM specialty and build three practical projects around these kinds of problems. It's $9.
Next time an employee says “I can't log in,” look beyond the password. There's a whole career field devoted to how access should work.