Authorization · Identity & access management · 3 min read
XACML With OpenID Connect, SAML, OAuth and SCIM: Who Does What
Short answer
SAML 2.0 and OpenID Connect tell an application who the user is, OAuth 2.0 lets a client call an API with limited delegated rights, SCIM creates and removes accounts in target systems, and XACML (or a similar policy engine) decides whether a specific action on a specific resource is permitted.
Key takeaways
- Each standard answers a different question; problems start when one is stretched to do another's job.
- OAuth scopes are coarse grants to a client; they are not a replacement for per-resource authorization.
- XACML's PEP/PDP/PIP/PAP architecture remains the reference model even where JSON policy engines have replaced its XML syntax.
Architecture diagrams for identity often look like alphabet soup: SAML here, OIDC there, OAuth on the APIs, SCIM to the SaaS apps and XACML somewhere in the middle. Each acronym is a standard with one main job. Once you see the jobs, the diagram becomes a lot easier to reason about.
What question does each standard answer?
SAML and OIDC answer "who is this?", OAuth answers "may this client call this API for the user?", SCIM answers "does this account exist with these attributes?", and XACML answers "is this action allowed right now?".
| Standard | Body, year | Job | Format |
|---|---|---|---|
| SAML 2.0 | OASIS, 2005 | Browser SSO, federation | XML assertions |
| OpenID Connect | OpenID Foundation, 2014 | Authentication on OAuth 2.0 | JWT ID tokens, JSON |
| OAuth 2.0 | IETF, RFC 6749 (2012) | Delegated API authorization | Access tokens |
| SCIM 2.0 | IETF, RFC 7643/7644 (2015) | Provisioning users and groups | JSON over REST |
| XACML 3.0 | OASIS, 2013 | Policy-based authorization decisions | XML (JSON profile available) |
How do they work together in one request?
A typical flow uses all five: SCIM created the account, OIDC signed the user in, OAuth issued the API token, and the API asked a policy decision point about the specific action.
Follow one user, Priya, a claims handler at an insurer:
- SCIM. When HR records her new role, the identity governance system creates her account in the claims application and adds her to the "claims-handlers" group, through the app's SCIM endpoint.
- SAML or OIDC. She opens the claims portal. It redirects to the company IdP, she authenticates with a security key, and the portal receives an ID token (or SAML assertion) with her identifier and group.
- OAuth. The portal's front end calls the claims API with an access token scoped to
claims:read claims:update, audienceapi://claims. - XACML. She tries to approve a payout of 18,000. The API's policy enforcement point sends a request to the policy decision point: subject attributes (role, region, approval limit), resource attributes (claim amount, region, status), action (approve). The PDP evaluates policies and returns Deny, because her limit is 10,000, along with an obligation to route the claim to a supervisor.
Each step is replaceable on its own. You could swap SAML for OIDC without touching the policies, or move from XACML to another engine without changing sign-in.
What is the XACML architecture?
Four components: the enforcement point intercepts requests, the decision point evaluates policy, the information point fetches attributes and the administration point manages policies.
- PEP (Policy Enforcement Point): code in the API or gateway that asks for a decision and enforces it.
- PDP (Policy Decision Point): evaluates the request against policies and returns Permit, Deny, NotApplicable or Indeterminate, plus obligations and advice.
- PIP (Policy Information Point): supplies attributes the request did not include, from a directory, database or HR system.
- PAP (Policy Administration Point): where policies are written, tested and versioned.
XACML 3.0 policies are XML, which few people enjoy writing by hand. The JSON profile simplifies the request and response format, and ALFA, a shorthand language, compiles into XACML. The authorization guide compares RBAC, ABAC and policy-as-code options.
Where do teams go wrong?
By using one standard for another's job.
- Pushing every permission into SAML attributes or JWT claims makes tokens huge and stale.
- Treating OAuth scopes as user permissions lets any user with a valid token act on any record.
- Using OIDC sign-in as account creation without SCIM leaves no clean way to remove accounts.
- Calling a PDP for every trivial check can add latency; cache decisions where policy allows.
To see what identity data your apps actually receive, decode a test ID token in the JWT Decoder or a SAMLResponse in the SAML Decoder.
Questions
Is XACML still used?
Yes, in sectors such as finance, government and healthcare that need auditable fine-grained authorization. Many newer projects use other policy engines and languages, such as Open Policy Agent with Rego or AWS's Cedar, but they follow the same decision-point architecture XACML defined.
Can OAuth scopes carry fine-grained permissions?
Only partly. Scopes describe what a client may do in general, like read:invoices. Whether this user may read this invoice is a separate decision your API must make. Rich authorization requests (RFC 9396) help for structured grants such as a specific payment.
Sources
Tagged: XACML, OpenID Connect, SAML, OAuth, SCIM, Authorization, IAM