Innomerc Choose your depth. Learn at your own pace.
Understand it
Authentication verifies an identity. Authorization checks permission. A valid login to Cedar Documents should let you read your own document, not every document in the company. Knowing who you are is only the start of the decision.
Think of entering an office with an identity badge. The badge can establish your identity, but a separate policy decides whether you may enter the records room. Applications need the same distinction for every protected operation.
Under the hood
Authentication may establish a server-side session or produce a token. The API then evaluates the subject, requested action, object, tenant and relevant context. The object identifier sent by the client is input to the decision, not proof of ownership.
Authorization belongs on the server at the point of access. Hiding a button only changes the interface. Central policy helpers can improve consistency, but each object and operation still needs correct scoping. Deny by default when policy information is missing.
Practitioner perspective
Test a permission matrix containing roles, tenants, ownership and operations. Include background jobs, exports, bulk endpoints and property changes; the visible detail page is only one access path. Roles alone may be insufficient for tenant or object relationships.
Log the decision and relevant subject/object identifiers without capturing protected payloads. Investigate unexpected permitted access as well as denied requests. An HTTP 200 response may still represent a policy failure if the requester received the wrong object.
Picture the idea: identity is not permission
Entering the building represents Authentication. Permission to open a particular cabinet represents Authorization. A server must check access to each resource; signing in alone is not enough.
Illustrated analogy · Select the image to enlargeWatch it work
A fictional, simplified model. Select a component to inspect it, or follow the steps in order.
Identity and access mechanisms
Compare the evidence exchanged, rather than treating every mechanism as a password replacement.
OAuth grants scoped access; it is not by itself a login protocol.
How to use this example
Select Next step to read at your own pace, or Animate step to watch one exchange. Nothing advances until you choose.
What it means
Everyday example
State in this scenario
Inspect components & read every step
- User / client
A person, or the software acting for them, beginning a sign-in or access request.
Example: You select Sign in and your browser starts the request.
- Identity service
A system that checks identity and manages sign-in decisions.
Example: It checks a password and may require an additional authentication factor.
- Application
Software that carries out a task for its user.
Example: A timetable app looks up the next bus departure.
- Authenticator
A device or method used to prove control of an authentication factor.
Example: A security key or an authenticator app helps verify a sign-in. Methods have different protections against phishing.
OAuth delegation
OAuth grants scoped access; it is not by itself a login protocol.
- User / client Identity service: Consent. The user authorizes a scoped client request.
- Identity service User / client: Code. The redirect carries a short-lived authorization code.
- User / client Identity service: Code + PKCE. The client exchanges the code with the required verifier.
- Identity service User / client: Access token. The authorization server issues a scoped token.
- User / client Application: Bearer token. The resource server validates the token and operation permissions.
OpenID Connect
OIDC adds an identity layer to OAuth flows.
- User / client Identity service: Sign in. The provider authenticates the user in a protected flow.
- Identity service Application: ID token. The client receives an ID token through its configured OIDC flow.
- Application User / client: Local session. Issuer, audience, signature and flow binding checks precede a session.
Passkey
The authenticator signs a challenge scoped to the relying party.
- Identity service User / client: Challenge. The relying party creates a fresh challenge.
- User / client Authenticator: User verification. The authenticator verifies the user under its policy.
- Authenticator Identity service: Signed assertion. The assertion binds the challenge and relying-party context.
- Identity service Application: Identity established. A valid assertion establishes the authenticated session.
SAML federation
A service provider validates a signed assertion and its intended recipient.
- User / client Application: Sign in. The service provider starts a federated sign-in.
- User / client Identity service: Authenticate. The identity provider authenticates the user.
- Identity service Application: SAML assertion. The service provider validates signature, audience, recipient and time.
- Application User / client: Session. The application establishes its own session.
Mutual TLS
Both peers prove control of certificate-associated private keys.
- User / client Application: ClientHello. TLS negotiation starts.
- Application User / client: Server proof. The client validates server certificate and handshake proof.
- User / client Application: Client proof. The server validates client certificate and handshake proof.
- Application User / client: Protected channel. Application authorization still applies above the channel.
Magic link
A short-lived, single-use link relies on access to the delivery inbox.
- User / client Identity service: Request link. The user asks for a sign-in link.
- Identity service Authenticator: Email link. The link is delivered to the registered inbox.
- Authenticator Identity service: Redeem. The service checks expiry and consumes the token once.
- Identity service Application: Session. A local session is established under policy.
Fictional teaching trace. One moving dot represents an exchange, not a measured network capture.
Open the detailed lesson walkthrough
Explore the system
Alex signs in
Credentials identify the requester.
Read every step without animation
Authentication
- Alex signs in. Credentials identify the requester.
- Identity verified. The service creates a session for Alex.
- Known subject. The service knows who made the next request.
Who are you? Alex.
Authorization
- Alex requests Sam’s document. Identity is known, but the object belongs to another user.
- Ownership check. The server evaluates whether Alex may read this document.
- Denied. The policy does not permit this access.
What can you do? Only what policy permits.
Explore deeper: additional experiment
Separate the two decisions
The identity check and this action’s permission check both pass. Permission for a different record or operation must be evaluated separately.
A local teaching model with fictional inputs. It does not test a live system.
Attack view
In the fictional visual, Alex is authenticated but asks for a document owned by Sam. An ownership check determines the outcome.
Defender view
- Verify permissions on every protected request.
- Scope database queries to the authorized tenant and subject where appropriate.
- Test cross-user, cross-role and cross-tenant boundaries.
Common mistakes
- A valid JWT does not grant access to every resource.
- A secret-looking object ID is not an authorization control.
Check your understanding
Active recall: explain this idea in 30 seconds
Authentication verifies an identity. Authorization checks permission. A valid login to Cedar Documents should let you read your own document, not every document in the company. Knowing who you are is only the start of the decision.
Now give an example and name one limitation. Revisit the explanation if you get stuck.
Primary sources
Original explanations informed by these specifications and official resources. Source versions and lesson review are separate from product updates.
Content reviewed 2026-09-10. Read the editorial policy.