Identity and token hand-off

SCL does not authenticate learners with its own login screen. It accepts a user bearer token from the parent platform and uses that identity to access product services and obtain narrower technical tokens.

Identities used in one attempt

Identity or token	Issued by	Used for	Browser retention
Learner bearer token	Parent platform / customer identity provider	Role-play API, evaluation, and technical-token exchanges	React memory
SCAI application access and refresh tokens	Integration Credentials	Voice signalling and renewal	React memory
Analytics technical token	Integration Credentials, called by the backend	Analytics sessions and events, when enabled	Backend memory/queue only
Learning-platform service token	Managed identity	Backend completion callback	Never exposed to the browser

The frontend also reads selected unverified JWT claims for orchestration:

exp determines when to request a refreshed user token.
upn can identify the analytics actor and learner completion record.
cmid identifies the course module for completion.

The receiving services remain responsible for authoritative identity and authorization.

User-token lifecycle

SCL announces that the embedded client is ready.
The parent sends the learner token and becomes the recorded parent origin for later messages.
Before role-play loading, voice-token acquisition, or evaluation, SCL reads the token expiry.
If expired, SCL asks the recorded parent for a replacement and waits up to ten seconds.
The refreshed token replaces the previous value in memory.

A missing initial token, an empty refresh response, or a refresh timeout leads to an authentication error screen.

SCAI and analytics token exchange

The role-play identifies the SCAI environment. SCL exchanges the learner token through Integration Credentials for a SCAI application token and refreshes or reacquires it as needed.

Analytics uses a separate technical token, but the browser does not call SCL Analytics or receive that token. The frontend sends analytics session and lifecycle requests to the Role Play Evaluation API, which obtains the technical token and proxies or queues delivery server-side. If token acquisition or analytics delivery fails, the learner’s voice session continues; analytics is treated as non-blocking.

The evaluation backend also exchanges the learner token for an AI Factory technical token. It does not send the original learner token to AI Factory.

Completion claims

After successful evaluation, the backend queues completion only if all of these values exist:

A target platform on the role-play.
A learner upn claim.
A course-module cmid claim.

If any value is missing, feedback still succeeds and completion is skipped.

Trust boundaries

The browser parses JWT data but does not validate its signature. The Evaluation API’s local JWT handler also disables issuer, audience, lifetime, and signature validation; production authentication therefore depends on the external gateway/middleware trust boundary and downstream Integration Credentials checks.

Consequences for integrators:

Do not expose the direct application endpoint as though its local JWT handler were authoritative.
Enforce token validation, authorization, CORS, and rate limits at the approved API boundary.
Restrict embedding to approved parent origins. The first token message establishes the origin trusted by the current client, so the host and framing policy are security-critical.
Never place tokens in URLs, persistent browser storage, logs, analytics metadata, documentation examples, or support tickets.

The unload beacon is an explicit exception: because sendBeacon cannot add an authorization header, it sends the learner bearer token in the JSON request body to the Evaluation API. The backend exchanges it for a technical analytics token before queueing the event; the user token is not placed on the analytics queue.