Sharing Browser Work Without Sharing Raw Credentials

Teams often say they need to “share a login” when the real need is narrower: review a draft, update an authorized storefront, reproduce a regional defect, or continue a support workflow. Starting from the task creates more options than starting from the password.

What counts as a raw credential

The obvious examples are passwords, recovery codes, one-time-password seeds, private keys, and proxy passwords. Browser work introduces less visible credentials too:

• authentication cookies and session identifiers;
• OAuth access and refresh tokens;
• password-manager records and autofill data;
• passkey private-key material or access to the authenticator that holds it;
• trusted-device and recovery state; and
• a profile archive that contains any of the above.

NIST’s session guidance describes a browser session as continuity based on possession of a session secret. The OWASP Session Management Cheat Sheet makes the operational consequence plain: while valid, a session token can be equivalent to the strongest authentication that created it.

An encrypted profile bundle does not expose those values to a storage provider or casual observer. After an authorized recipient’s device decrypts and launches the profile, the browser can still exercise the session. The handoff has transferred authority even if the recipient never reads a cookie.

Separate the task from the authority

Before choosing a sharing mechanism, write a small access statement:

Named operator A may perform actions B on resource C, from approved device D, until time E, with approval and audit rule F.

That sentence exposes unnecessary authority. If the task is “approve this draft”, a full administrative session is excessive. If the target service already supports a reviewer role, sharing browser state adds risk without adding capability.

NIST’s Zero Trust Architecture recommends access to individual resources on a per-session basis with the least privileges needed for the task. This principle applies without adopting a product labeled “zero trust”. It is a useful design test for any browser handoff.

Prefer these models in order

1. Named access at the target service

Use the website or application owner’s own team, organization, role, delegation, or approval feature when it exists. Each person authenticates with an individual account and authenticator. The target service can then enforce its permissions, attribute actions to the operator, apply its risk controls, and revoke one person without changing everybody’s credential.

This is usually the strongest model because authorization lives where the action is understood. A browser manager cannot reliably convert one site’s shared administrator session into a site-level reviewer role.

Shared and group accounts reduce accountability. NIST SP 800-53 Rev. 5 advises organizations to restrict their use and define explicit conditions before permitting them.

2. Scoped delegation from the target service

When a service offers OAuth or another delegation protocol, grant a client or actor only the required resources, actions, and lifetime. RFC 9700 recommends restricting access-token privileges to the minimum required and limiting the audience to the intended resource server.

Prefer short-lived, revocable, audience-restricted grants. Sender-constrained tokens can reduce replay if a token leaks, but they do not help when an attacker obtains both the token and its bound key material. The client device and software remain inside the threat boundary.

Delegation is especially useful for automation because a script can receive permission for a defined operation without receiving a person’s password or general browser session. The audit event should identify the initiating person, the delegated actor, the resource, the scope, and the result.

3. Brokered use of a stored secret

Some legacy services expose only a shared credential. A controlled credential broker or password manager can reduce copying by allowing an approved browser flow to use a secret without showing it in chat, tickets, documents, or normal application output.

This improves custody, rotation, and access review, but it does not repair the target service’s account model. After sign-in, every operator may still act as the same site identity. The resulting session remains sensitive and needs its own timeout, revocation, and device controls.

The OWASP Secrets Management Cheat Sheet recommends fine-grained access, minimum human interaction with secret values, lifecycle controls, and auditing of who requested and used a secret. A browser product should integrate through an opaque reference where possible, rather than becoming another general-purpose secret store.

4. Protected browser-session handoff

Use a shared authenticated profile only when the target service lacks adequate delegation and the authorized workflow genuinely needs session continuity. This is the highest-risk normal handoff because the recipient receives the ability to act through the live account.

Minimum controls include:

• an explicit owner and approved recipient;
• a stated task, resource, and expiry time;
• one active writer or a tested conflict model;
• client-side encryption before any cloud upload;
• recipient-device authorization and local protection;
• a lock that prevents ambiguous simultaneous work;
• audit events for grant, download, open, sensitive action, close, revoke, and recovery;
• normal interfaces that return redacted state instead of cookies or tokens; and
• a target-service session-revocation plan.

This model can protect the credential value from casual copying and cloud storage. It cannot make the target service distinguish two people using the same authenticated account. It also cannot protect the session from malware, a malicious extension, or an authorized recipient who misuses the granted authority.

5. Raw credential transfer

Copying a password, cookie, recovery code, passkey, or profile archive into a message, spreadsheet, ticket, script, or unprotected export creates a durable secret with unclear copies and weak revocation. Avoid it.

If an exceptional legacy process requires a transfer, handle it under the organization’s approved credential procedure, minimize recipients and lifetime, and rotate or revoke the credential afterwards. Do not treat encryption of the message as a substitute for individual accountability or a record of every copy.

Compare the authority, not only the convenience

Model	Target service identifies the operator	Scope can match the task	Revocation boundary	Main residual risk
Named target-service member	Usually yes	Usually strongest	Remove one member or role	Excess target-service permissions
Scoped delegated token	Actor and client can be represented	Strong when scopes and audience are narrow	Revoke grant or token	Token, client, or key compromise
Brokered shared sign-in	Often no after sign-in	Limited by the shared account	Rotate secret and terminate sessions	Shared site identity and live sessions
Encrypted browser session	Usually no at the target service	Profile-level, often broad	Revoke share plus target session	Recipient device can exercise full session authority
Raw credential copy	No reliable individual identity	Usually broad	Find copies, rotate, and terminate sessions	Unknown copies and weak accountability

The table explains why “nobody can see the password” is an incomplete success criterion. The important result is how much authority the recipient can exercise, how long it lasts, and which system can revoke it.

Passkeys improve authentication, with a sharing caveat

WebAuthn creates a public-key credential scoped to a relying party. The WebAuthn Level 3 specification says the authenticator holds the private key and the website’s script receives signed results, not the private credential itself. This provides phishing-resistant authentication when correctly deployed.

Passkeys do not automatically create team roles. A target service can register a separate credential for each named member, which preserves individual access. A passkey provider may also support synchronizing or sharing authentication keys. NIST SP 800-63B-4 recognizes that model and also identifies risks such as unauthorized key use, proliferation across devices, sync-fabric compromise, and difficult revocation.

For an authorized team, prefer one named service account and authenticator per person. If a shared passkey is the only supported model, treat it as a shared authenticator, document who can receive it and on which managed devices, and verify how the provider displays, revokes, and recovers shared keys. The target service may still record every action under one account.

Define the browser handoff as a contract

A controlled handoff should answer these questions before profile state moves:

1. Who is acting? Use a named organization identity, never a generic operator label.
2. Who authorized it? Record the owner or policy decision without storing approval secrets.
3. What is shared? Name the profile and task. Avoid raw inventory of its cookies or credentials.
4. What may the recipient do? Separate launch, edit, export, automation, sharing, and administrative permissions.
5. Where may it run? Limit access to enrolled, trusted devices appropriate to the data.
6. How long does it last? Set an expiry and close idle sessions.
7. Can two writers act? Use one active writer unless conflict behavior is deliberately designed and tested.
8. What is recorded? Log actor, device, profile reference, action, result, and time. Exclude secret values and page content by default.
9. How is it revoked? Cover both the browser-sharing grant and the target-service session.
10. How is it recovered? Preserve a last-known-good version without restoring revoked authority by accident.

Encryption belongs inside this contract. It protects data while stored or transferred. Authorization decides who may obtain the decryption path. Device trust and local isolation protect use. Audit supports accountability and investigation. None of these controls replaces the others.

Keep automation outside the secret boundary

APIs, SDKs, command-line tools, and agents often need to start a profile or perform an approved lifecycle action. They rarely need cookie values, passwords, passkeys, proxy credentials, or a raw profile archive.

A narrow interface can accept an opaque profile or secret reference and return:

• whether the action was authorized;
• a redacted state such as ready, locked, expired, or revoked;
• a process or session reference with a limited lifetime;
• a structured error and recovery step; and
• an audit-event reference.

It should not return a credential merely because the caller can launch the profile. Export, bulk sharing, or another secret-bearing operation needs separate policy and, where appropriate, explicit approval.

Content from websites and automation inputs also remains untrusted. A page instruction must not be able to persuade an agent to reveal session material through logs, tool output, screenshots, or a support channel.

Revocation has two layers

Removing a collaborator from a browser workspace stops future authorized access through that workspace. It does not prove that the target-service session is invalid. A device may already hold decrypted state, and a copied or still-running session may continue.

When access ends normally:

1. revoke the team grant and close the profile lease;
2. remove encrypted local material according to the retention policy;
3. terminate the relevant session at the target service where supported;
4. remove the person’s target-service membership or delegated grant; and
5. retain redacted audit evidence for the approved period.

When compromise is suspected, also quarantine affected profile versions, revoke active sessions and tokens, remove unauthorized authenticators, rotate exposed shared secrets, and review audit events. Restoring an older profile snapshot can restore an old session secret, so recovery must respect revocation state.

Limits that remain after a careful handoff

• Client-side encryption protects stored and transmitted data, but an authorized endpoint must decrypt what the browser needs.
• A browser lock controls product-level concurrency, not every action at the target service.
• A shared session usually gives the target service one account identity, regardless of the browser product’s richer audit trail.
• A compromised device or extension can act through a valid session without extracting a readable password.
• Revoking a workspace grant and revoking a website session are separate operations.
• The target service’s terms, client contract, and applicable law still determine whether a workflow may be delegated.
• Some services provide no safe substitute for individual access. In that case, reducing scope or declining the handoff may be the responsible outcome.

RFC 6265 describes cookies as ambient authority: a browser can attach them to a request even when the party causing the request never knows the cookie value. This is the central limitation of session sharing. Concealed credentials reduce disclosure; they do not reduce the authority that the browser can exercise.