Somebody is reading a page inside a product you have never heard of. They are already logged in — they signed in this morning, to that product, with that product's password. They leave a review, and it appears under their name, attributed and moderatable.
The component that recorded it is Revws, a reviews-and-ratings layer ML LABS builds and operates in the internal portfolio at Escape Velocity Labs, a sister practice under the same owner. It never saw that password. It never issued that person a credential, holds no session for them, and could not log them in if it wanted to. The host product did all of that, minutes ago, and then said so in a signed token — and everything else about the product's design follows from that one sentence.
Selling a component that drops into other companies' products looks like a UI problem and is an identity problem. You cannot ask the host's users to create a second account: no product will install a component that makes its users authenticate twice, and no user would do it. You also cannot be trusted to manage the host's identity, and should not want to be. But the component still needs to know who the user is, because a review that cannot be attributed and moderated is worthless — which leaves exactly one place to stand.
Federate Identity, Do Not Own It
The host is the identity authority. It already authenticated the user, so it mints a short-lived token asserting who that user is, and Revws verifies the signature and trusts the assertion. The token is HS256-signed with a secret held per product — one host, one signing secret, no shared key that turns a single compromise into every customer's compromise.
That split is what makes the component adoptable at all. Revws is a verifier, never a store of credentials; the host never surrenders control of its users; and the token carries the claims the widget needs and nothing more.
- The host authenticates; the widget verifies. Neither ever does the other's job.
- One signing secret per product, so the blast radius of a leaked secret is one customer.
- Workspace admins are the exception, and they are handled by an entirely separate path.
That last point is the one the whole promise rests on, so it is worth stating precisely. Revws does run a conventional identity provider — Cognito — but only for workspace admins, the people who configure the product and moderate its content. The federated path, the one that carries the host's end users, never touches Cognito at all. Two populations, two mechanisms, no overlap: the moment an end user's identity starts flowing through the admin system, the widget has quietly become the thing it promised the host it would never be. Keeping those code paths separate is the same discipline that stops bounded contexts from leaking into each other (Fowler, 2014) — the widget's job ends precisely where the host's identity begins, and the token is the treaty across the line.
Own The Record, Rent The Identity
Borrowing identity does not mean borrowing the data. The reviews, ratings, and reactions the widget collects are the durable asset, and they belong to the customer whose product they were written in — exportable, portable, theirs.
The distinction is commercial as much as ethical. A component that traps a customer's accumulated reviews in a silo is a component that customer will eventually engineer their way out of, and the exit will not be friendly. The trust the widget displays to end users has to be matched by the trust it keeps with the business that installed it. Rent the identity. Own nothing you would not hand back.
The Token Is The Attack Surface
When trust rides on a signed assertion, the assertion is the entire security perimeter. A forged token is a forged user, and a forged user in a reviews system is fabricated social proof — precisely the thing the product exists to prevent. So the token contract is not a detail of the design; it is the design, and Revws is deliberately paranoid about it.
The maximum token lifetime is fifteen minutes, and the clock-skew tolerance is thirty seconds. Those two numbers are the whole risk budget. A stolen token is a stolen identity for as long as it validates, so its lifetime is not a convenience knob to be turned up when someone complains about re-minting — it is the blast radius, chosen on purpose. Thirty seconds of skew is the concession to the fact that two servers never agree on the time, and it is deliberately small: the JWT specification's own guidance (IETF, 2015) permits leeway of "no more than a few minutes", and minutes of leeway are minutes of extra life for a replayed token.
Every embedded component is asking its host for trust. A signed, expiring token is the only honest way to ask — and the expiry is the only honest way to give it back.
The rest of the contract is the part that the best-practice guidance for JSON Web Tokens (IETF, 2020) exists to enforce, and it is unglamorous: verify the signature on every request rather than trusting a token once at load; pin the algorithm rather than believing the token's own header about how it was signed; check that the token was minted for this audience and not lifted from somewhere else. Get those three wrong and the fifteen-minute lifetime protects nothing. The category of identification and authentication failures (OWASP) is the standing catalogue of what happens next, and embedded components live at the top of it — which is the one genuinely good thing about a federated design. It concentrates the risk into a single artifact. There is one thing to get right instead of many, and the security review of the whole product is, in the end, the security review of the token.
When Embedding Multiplies Blast Radius
There is a boundary where an embedded component stops being a convenience and becomes a systemic risk to everyone who installed it, and it arrives with reach rather than with load. This is a property of the delivery model, not a statistic about any one product: code served from a CDN executes in every page that embeds it, so a vulnerability is not one breach but one per host, and a bad deploy is not one outage but one per host, arriving simultaneously and without anyone's consent. The leverage that makes an embedded component valuable is exactly the leverage that makes its failures spread, and the operational bar it raises is the one the companion piece on what enterprise agent deployment actually takes sets out at organizational scale.
Code that ships into other people's pages is not a contained product, and reasoning about it as one is the mistake. It runs under someone else's content-security policy, next to someone else's data, in front of someone else's users, on a version they did not choose to upgrade to. That environment demands a standard of isolation, versioning, and backward compatibility that a self-contained app never has to meet — and it demands that failures degrade rather than propagate, because designing for graceful degradation under partial failure (Google, 2016) is what decides whether the host's page survives your bad afternoon. A reviews component that is down should mean a page without reviews, never a page that will not render. This is the same seam, seen from the host's side, that the companion piece on refusing to rebuild what others already own argues for buying rather than building.
First Steps
- Settle who authenticates before you write a line of the component. The host owns login; you verify a signed claim. Designing your own login into an embeddable widget is a dead end you will pay to reverse.
- Write the token contract down as a contract — algorithm, audience, maximum lifetime, skew tolerance, per-tenant secret — and treat it as the security review of the entire product, because it is.
- Keep two identity paths that never meet: the host's end users through federation, your own administrators through a conventional provider. If those paths ever converge, the promise you sold the host is broken and nobody will tell you.
Ship The Trust Boundary First
The durable order is to design the federation boundary before anything else — who authenticates, who verifies, what the token asserts, how long it lives, what happens when it does not arrive. Everything else in an embeddable component depends on that contract being right, and no amount of interface polish compensates for getting it wrong. A component designed identity-first is safe to drop into any host. One that treats identity as an afterthought becomes the weakest link in every product that installed it, and the primitive-and-audit-trail argument for agent-native systems is the same claim in a different setting: model the principal properly or govern nothing.
The trust boundary is also the part that is hardest to retrofit, because by the time a serious host asks the hard security questions, the answer has already been designed in or designed out. Carrying trusted identity across a boundary you do not control is the definition of an AI system integration — the engagement is accepted against written targets by the people who will actually use the system, and it includes its first 60 days of Operate, run by the person who built it, which is when a token contract meets its first real host and finds out whether it was honest. Design the boundary first, and the rest of the component is just work.
References
- Internet Engineering Task Force. JSON Web Token (JWT). RFC 7519, 2015.
- Internet Engineering Task Force. JSON Web Token Best Current Practices. RFC 8725, 2020.
- Open Worldwide Application Security Project. OWASP Top Ten. OWASP.
- Fowler, M. BoundedContext. martinfowler.com, 2014.
- Google. Monitoring Distributed Systems. Site Reliability Engineering, 2016.
