Puede hacer que A.com cree un token de N bits aleatorio utilizado como clave en un almacén de claves. Luego, A.com envía al usuario un enlace a B.com que contiene este token en claro. El usuario accede a B.com con ese token, y B.com puede ponerse en contacto con A.com "de forma privada" y recuperar los datos asociados, por lo que A.com puede invalidar el token para que no pueda ser reutilizado.
Dado el corto tiempo de viaje de ida y vuelta (todos los enlaces son redirecciones que deben ser manejadas automáticamente por el navegador del usuario), A.com podría justificarse al rechazar solicitudes de token de tokens más antiguas que, digamos, 30 segundos:
user --> B.com "log me in"
B.com --> user "Go to A.com/logmein/$RANDOM1" { cookie B.com:RANDOM1 }
user --> A.com "log me in"
(login procedure)
A.com --> user "Go to B.com/loggedin/$RANDOM2" [START "A" TIMER]
user --> B.com "my token is $RANDOM2 (and my cookie is $RANDOM1)"
B.com --> A.com "What about $RANDOM2:$RANDOM1?" [STOP "A" TIMER]
Ahora A.com ha almacenado $ RANDOM1 en la primera solicitud, reconoce $ RANDOM2 como de su propia creación, la marca de tiempo es válida, por lo que en el enlace AB puede transmitir todo tipo de información secreta sin que el usuario lo sepa.