What does `<AudienceRestriction>` constrain in a SAML assertion, and what does a missing one allow?

middlemust knowfreq 52%

answer

an address line, not a name
entityID of a party, not a person
required by the browser single sign-on profile
absent means addressed to whoever reads it
missing expiry is the worse omission

basics

~20 s

AudienceRestriction names, by entityID URI, the parties the assertion is addressed to; anyone not named must not rely on it. With none present, every service provider that receives a copy can read it as addressed to itself, and nothing in the document contradicts that.

solid answer

~40 s

<AudienceRestriction> sits inside <Conditions> and holds one or more <Audience> elements, each an entityID URI naming a party the statement is meant for. It addresses the document. The Web Browser SSO profile requires a bearer assertion to carry one containing the service provider's own identifier, and a relying party that is not named in it must not act on the statement. Remove the element and the statement becomes addressable by whoever holds it: a copy handed to a low-value service provider reads exactly as well at a high-value one, so the weakest counterparty in a federation becomes the way into the strongest. Several <Audience> values mean any one of them may rely on it, which is a deliberate widening and not a default.

`<AudienceRestriction>` sits inside `<Conditions>` and holds one or more `<Audience>` elements, each an `entityID` URI naming a party the statement is meant for. It addresses the document. The Web Browser SSO profile requires a bearer assertion to carry one containing the service provider's own identifier, and a relying party that is not named in it must not act on the statement. Remove the element and the statement becomes addressable by whoever holds it: a copy handed to a low-value service provider reads exactly as well at a high-value one, so the weakest counterparty in a federation becomes the way into the strongest. Several `<Audience>` values mean any one of them may rely on it, which is a deliberate widening and not a default.

code

xml · 8 lines

xml

<saml:Conditions NotBefore="2026-09-19T08:13:52Z"
                 NotOnOrAfter="2026-09-19T08:24:02Z">
  <saml:AudienceRestriction>
    <!-- the entityID of the intake service, not of the driver -->
    <saml:Audience>https://intake.coop.example/sp</saml:Audience>
  </saml:AudienceRestriction>
  <saml:OneTimeUse/>
</saml:Conditions>

go deeper

for a junior

Know that a SAML assertion carries an address line naming the service it was issued for, and that a service not named in it should refuse the statement.

for a middle

Explain that Audience holds an entityID naming a party while NameID names the person, and what a reader gains by finding its own identifier there.

for a senior

Reason about the estate: with no audience restriction, the least defended service that receives assertions becomes a source of statements every other service will read.

for a principal

Weigh where you accept shared-audience assertions across a group of services at all, since each widening makes one compromise reach further than the service it started in.

What the element does

<AudienceRestriction> is a condition, so it lives inside <Conditions>, alongside the validity window. It holds one or more <Audience> elements, and each <Audience> is a URI — in practice the entityID of a service provider. It is the assertion's address line: this statement is for these readers.

It is worth being precise about what kind of name that is. An <Audience> names an organisation's service, not a person. The person is named by the <NameID> in the <Subject>. One assertion therefore carries two identifiers of completely different kinds, and mixing them up is the most common reading error in this part of the grammar.

The rule that goes with it

The core grammar makes <AudienceRestriction> optional. The Web Browser SSO profile does not: an assertion carrying a bearer subject confirmation must include an <AudienceRestriction> naming the service provider's own unique identifier as an <Audience>. A reader that does not find itself named there is being handed someone else's post.

There is a second core rule that people forget: an assertion whose <Conditions> carries a condition the reader cannot evaluate is not usable. Conditions are not hints. Any element inside <Conditions> is something the issuer is asking the reader to apply, and a reader that cannot apply it has no basis for relying on the statement.

What a missing audience buys an attacker

At the grain co-operative, the intake system is one of eleven services the co-operative's own identity provider issues assertions for. The others include a low-traffic seed-catalogue site run by one department.

With <AudienceRestriction> present and correct, an assertion minted for the catalogue site is refused at the intake system, because the intake system does not appear in the address line. Without it, the same document is a statement about that driver addressed to nobody in particular — and the intake system has no element in the document that says otherwise. The weakest service in the estate becomes a supply of statements the strongest will read.

This is why the element is often described as turning one statement into a general-purpose one. Nothing about the statement's content changed; what changed is that the reader was no longer told it was not for them.

And why a missing time window is worse

Compare the two omissions:

Omission	What it costs	Bounded by anything else?
no `<Audience>`	any reader can treat it as addressed to itself	still expires at `NotOnOrAfter`
no `<Conditions>` `NotOnOrAfter`	the statement never lapses	the bearer window may still bound delivery, if present
neither	a permanently usable statement any reader will accept	nothing

A missing audience produces a document that is over-addressed but still perishable. A missing upper time bound produces one that keeps working — and a document that keeps working is a far larger problem than one that works too widely for ten minutes.

The other conditions in the same element

Two more conditions are worth knowing because they are the ones people meet and misread:

<OneTimeUse> — the issuer telling the reader that this statement must not be retained in a form that would let it be relied on again. It is a condition on the reader's behaviour, carried in the document; it does not itself make the document single-use.
<ProxyRestriction> — a limit on assertions issued onward from this one, where the reader is itself an identity provider for somebody else. Its Count limits the depth and its <Audience> children limit who those onward statements may be addressed to.

Multiple audiences

Several <Audience> elements inside one <AudienceRestriction> mean the statement is addressed to any of those parties. That is a deliberate widening — a shared statement for a group of related services — and not something to do by accident. Two separate <AudienceRestriction> elements are the narrower construction: the reader must satisfy each restriction.

What to take away

<Audience> names a party by entityID; <NameID> names the person. Different identifiers, different jobs.
The browser single sign-on profile requires the reader's own identifier to appear.
A missing audience makes the weakest reader in the estate a source of statements the strongest will accept.
A missing NotOnOrAfter is the worse omission, because it removes the bound that the audience omission still leaves behind.

## What the element does `<AudienceRestriction>` is a condition, so it lives inside `<Conditions>`, alongside the validity window. It holds one or more `<Audience>` elements, and each `<Audience>` is a URI — in practice the `entityID` of a service provider. It is the assertion's address line: *this statement is for these readers*. It is worth being precise about what kind of name that is. An `<Audience>` names an **organisation's service**, not a person. The person is named by the `<NameID>` in the `<Subject>`. One assertion therefore carries two identifiers of completely different kinds, and mixing them up is the most common reading error in this part of the grammar. ## The rule that goes with it The core grammar makes `<AudienceRestriction>` optional. The Web Browser SSO profile does not: an assertion carrying a bearer subject confirmation must include an `<AudienceRestriction>` naming the service provider's own unique identifier as an `<Audience>`. A reader that does not find itself named there is being handed someone else's post. There is a second core rule that people forget: an assertion whose `<Conditions>` carries a condition the reader cannot evaluate is not usable. Conditions are not hints. Any element inside `<Conditions>` is something the issuer is asking the reader to apply, and a reader that cannot apply it has no basis for relying on the statement. ## What a missing audience buys an attacker At the grain co-operative, the intake system is one of eleven services the co-operative's own identity provider issues assertions for. The others include a low-traffic seed-catalogue site run by one department. With `<AudienceRestriction>` present and correct, an assertion minted for the catalogue site is refused at the intake system, because the intake system does not appear in the address line. Without it, the same document is a statement about that driver addressed to nobody in particular — and the intake system has no element in the document that says otherwise. The weakest service in the estate becomes a supply of statements the strongest will read. This is why the element is often described as turning one statement into a general-purpose one. Nothing about the statement's content changed; what changed is that the reader was no longer told it was not for them. ## And why a missing time window is worse Compare the two omissions: | Omission | What it costs | Bounded by anything else? | |---|---|---| | no `<Audience>` | any reader can treat it as addressed to itself | still expires at `NotOnOrAfter` | | no `<Conditions>` `NotOnOrAfter` | the statement never lapses | the bearer window may still bound delivery, if present | | neither | a permanently usable statement any reader will accept | nothing | A missing audience produces a document that is over-addressed but still perishable. A missing upper time bound produces one that keeps working — and a document that keeps working is a far larger problem than one that works too widely for ten minutes. ## The other conditions in the same element Two more conditions are worth knowing because they are the ones people meet and misread: - **`<OneTimeUse>`** — the issuer telling the reader that this statement must not be retained in a form that would let it be relied on again. It is a condition on the reader's behaviour, carried in the document; it does not itself make the document single-use. - **`<ProxyRestriction>`** — a limit on assertions issued *onward* from this one, where the reader is itself an identity provider for somebody else. Its `Count` limits the depth and its `<Audience>` children limit who those onward statements may be addressed to. ## Multiple audiences Several `<Audience>` elements inside one `<AudienceRestriction>` mean the statement is addressed to **any** of those parties. That is a deliberate widening — a shared statement for a group of related services — and not something to do by accident. Two separate `<AudienceRestriction>` elements are the narrower construction: the reader must satisfy each restriction. ## What to take away - `<Audience>` names a party by `entityID`; `<NameID>` names the person. Different identifiers, different jobs. - The browser single sign-on profile requires the reader's own identifier to appear. - A missing audience makes the weakest reader in the estate a source of statements the strongest will accept. - A missing `NotOnOrAfter` is the worse omission, because it removes the bound that the audience omission still leaves behind.

Two `<Audience>` elements appear inside one `<AudienceRestriction>`. Who may rely on the assertion?
Either of them. Multiple `<Audience>` values inside one restriction widen the address line to any of the named parties. The narrower construction is two separate `<AudienceRestriction>` elements, each of which the reader must satisfy. Widening should be a deliberate decision for a group of related services, not an accident of configuration.
Does `<OneTimeUse>` stop an assertion being presented twice?
Not by itself. It is a condition addressed to the reader: the issuer is saying this statement must not be retained in a form that could be relied on again. Enforcing that is the reader's obligation. The element expresses the requirement; it carries no mechanism, and a reader that ignores conditions is unaffected by its presence.
Which is the more dangerous omission in a SAML assertion: no `<AudienceRestriction>` or no `<Conditions>` `NotOnOrAfter`?
The missing `NotOnOrAfter`. A statement with no address line is still perishable, so the exposure ends when the window closes. A statement with no upper time bound keeps working, and if it also carries no audience it is a permanently addressable statement about that subject.

A signed delivery note made out to one mill can be refused at every other gate. Leave the addressee blank and the note itself stops being the thing that decides which gate accepts it.

saying these in an interview costs you the question

Thinks Audience names the user rather than the receiving party.
Says AudienceRestriction is optional guidance a reader may skip.
Believes OneTimeUse by itself prevents a second presentation.
Assumes several Audience values narrow the statement rather than widen it.
Calls a missing audience worse than a missing expiry time.

What does `<AudienceRestriction>` constrain in a SAML assertion, and what does a missing one allow?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What the element does

The rule that goes with it

What a missing audience buys an attacker

And why a missing time window is worse

The other conditions in the same element

Multiple audiences

What to take away

▾common follow-ups3 questions

▾analogy~10 s

▾red flags5 flags

What the element does

The rule that goes with it

What a missing audience buys an attacker

And why a missing time window is worse

The other conditions in the same element

Multiple audiences

What to take away

answer

go deeper