OneSpan Sign Developer: sesión, token de autenticación y URL de firma - Parte2

En el primera parte de esta serie de blogs, cubrimos diferentes ciclos de vida y funciones de los tokens de sesión y autenticación, y discutimos los tres factores que hacen que una URL de firma sea diferente de la generada por el token de autenticación. Por ahora, ya puede seleccionar una solución para generar URL para su ceremonia de firma.

Por lo tanto, nos centraremos principalmente en las preocupaciones de nivel de codificación de estos tres conceptos y el resto de los detalles que pueden interesarle.

Fichas de autenticación de uso único y uso múltiple

Hay dos tipos de tokens de autenticación: uso único y uso múltiple. Una URL con un token de un solo uso solo puede permitir que el firmante tenga acceso a la ceremonia de firma una vez. Si el firmante actualiza o cierra la página o la ventana principal redirige la URL, no puede volver a la ceremonia de firma utilizando el mismo enlace.

El token de uso múltiple literalmente significa que los firmantes pueden volver a la ceremonia de firma en cualquier momento siempre que el token no haya expirado. Pueden usar el mismo token varias veces.

Tanto los tokens de uso único como los de uso múltiple tienen su lugar. Elegir entre ellos depende de sus propios requisitos únicos.

Los códigos a continuación demuestran cómo puede recuperar un token de autenticación para un firmante específico utilizando los métodos SDK y API:

SDK de Java:

Cadena signerAuthToken = eslClient.getAuthenticationTokensService (). CreateSignerAuthenticationToken (nuevo PackageId (packageId), signerId); // token de autenticación de uso múltiple
Cadena singleUseToken = eslClient.getAuthenticationTokensService (). CreateSignerAuthenticationTokenForSingleUse (packageId, signerId, null); // token de autenticación de un solo uso

.Net SDK:

cadena signerAuthToken = eslClient.AuthenticationTokenService.CreateSignerAuthenticationToken (nuevo PackageId (packageId), signerId); // token de autenticación de uso múltiple
cadena singleUseToken = eslClient.AuthenticationTokensService.CreateSignerAuthenticationTokenForSingleUse (packageId, signerId, signerSessionFields); // token de autenticación de un solo uso

API REST

Solicitud HTTP
POST / api / autenticaciónTokens / signer / multiUse // para uso múltiple
POST / api / authenticationTokens / signer / singleUse // para un solo uso
Encabezados HTTP
Aceptar: aplicación / json
Tipo de contenido: application / json
Autorización: Basic api_key
Solicitar carga útil
{
    "packageId": "5vjLRY5MWrDJ6MzRAEyCKOy5IH0 =",
    "signerId": "8b734331-bc5b-4843-9784-d4ece4b7dc22"
}
Carga útil de respuesta
{
   "packageId": "5vjLRY5MWrDJ6MzRAEyCKOy5IH0 =",
   "signerId": "8b734331-bc5b-4843-9784-d4ece4b7dc22",
   "value": "ZDNmMDNiNGUtNGYxOC00YWZiLTkwMmUtNWE5YmIwZTRjZDg1"
}

Cada uno de estos métodos generará un token, como el siguiente, que se compone de letras mayúsculas y minúsculas, así como números.

NDlkZjEyOWYtODFmYy00NDI2LWJhNDYtZTVjMmE3ZGI1YjEy

Se combina con mayúsculas, minúsculas y número.

Nota:

1) La identificación del firmante en esta llamada SDK / API se puede reemplazar por el correo electrónico del firmante.

2) El token de autenticación solo se puede generar cuando el paquete está en estado “ENVIADO” o “COMPLETADO”.

3) Si modificó el correo electrónico de su firmante en su flujo de trabajo, deberá generar un nuevo token de autenticación, porque su correo electrónico también se validará al acceder a la ceremonia de firma. Si esta validación falla, el firmante será redirigido a una página que se parece a la siguiente captura de pantalla:

Después de recuperar el token de autenticación, puede obtener una sesión de firma creando la siguiente URL:

https://sandbox.esignlive.com/access?sessionToken={signerAuthToken}

URL de firma

En Java SDK, puede generar una URL de firma directamente utilizando esta función:

String signatureUrl = eslClient.getPackageService (). GetSigningUrl (nuevo PackageId ("id del paquete"), "Id. Del firmante"); // en este caso, la identificación del firmante no se puede reemplazar por correo electrónico

Y en .Net SDK:

string signUrl = eslClient.PackageService.GetSigningUrl (nuevo PackageId ("id del paquete"), "id del firmante"); // en este caso, la identificación del firmante no se puede reemplazar por correo electrónico

Al usar un SDK para generar la URL de firma, OneSpan Sign le solicita que use la ID del firmante en lugar del correo electrónico o la ID del rol. Por lo tanto, cuando se crea un objeto de firmante, se recomienda encarecidamente una función withCustomId () para sincronizar ID de rol e ID de firmante.

Solicitud HTTP
GET / api / packages / {packageId} / roles / {roleId} / SignatureUrl
Encabezados HTTP
Aceptar: aplicación / json
Tipo de contenido: application / json
Autorización: Basic api_key
Carga útil de respuesta
{
  "roleId": "2jsTTXD2dZMZ",
  "url": "https://sandbox.e-signlive.com/auth?target=https %3 UNA %2 F %2 Fsandbox.esignlive.com \ r \ n %2 Paquetes %2 FnaXQwWFSQB9RkOiH6AguBCkXp2k = %2 Fsign & loginToken = \ r \ nMi4xMDAwGpGY3JJPS55ZnNSeHBmekNxc1RzdnNJRVlBSDkZBR1RhcmxKS09aZ3M4aFZXVlpvdExrdz09 ",
  "packageId": "a3b023bf-db56-4c53-b36e-bd9acd0579f4"
}

En descanzo

Esto difiere del SDK porque requiere una ID de rol en lugar de una ID de firmante.

Nota:

Similar al token de autenticación, la URL de firma está vinculada a un correo electrónico específico. Si cambia el correo electrónico de su firmante, asegúrese de volver a ejecutar la función y crear una nueva URL de firma.

A través de este blog, hemos demostrado cómo recuperar mediante programación un token de autenticación y una URL de firma. Juntos con primera parte de este blog , usted puede tenga más flexibilidad en sus elecciones cuando desarrolle tokens de autenticación.

Si tiene alguna pregunta sobre este blog o cualquier otra cosa relacionada con la integración de OneSpan Sign en su aplicación, visite el Foros de la comunidad de desarrolladores . ¡Sus comentarios nos importan!