Développeur de signes OneSpan : Session, jeton d'authentification et signature url - Partie2

Dans la première partie de cette série de blog, nous avons couvert différents cycles de vie et devoirs de jetons de session et d’authentification, et nous avons discuté des trois facteurs qui rendent une URL de signature différente de celle générée par le jeton d’authentification. À présent, vous êtes déjà en mesure de sélectionner une solution pour générer des URL pour votre cérémonie de signature.

Par conséquent, nous nous concentrerons principalement sur les préoccupations de niveau de codage de ces trois concepts et le reste des détails qui peuvent vous intéresser.

Jetons d'authentification à usage unique et à usage multiple

Il existe deux types de jetons d'authentification : l'utilisation unique et l'utilisation multiple. Une URL avec un jeton d'utilisation unique ne peut permettre au signataire d'accéder à la cérémonie de signature qu'une seule fois. Si le signataire actualise ou ferme la page ou que la fenêtre parente redirige l'URL, il ne peut pas retourner à la cérémonie de signature en utilisant le même lien.

Le jeton d'utilisation multiple signifie littéralement que les signataires peuvent revenir à la cérémonie de signature à tout moment tant que le jeton n'est pas expiré. Ils peuvent utiliser le même jeton plusieurs fois.

Les jetons à usage unique et les jetons à usage multiple ont leur place. Choisir entre eux dépend de vos propres exigences uniques.

Les codes ci-dessous montrent comment vous pouvez récupérer un jeton d'authentification pour un signataire spécifique en utilisant des méthodes SDK et API :

Java SDK:

Signataire de cordesAuthToken - eslClient.getAuthenticationTokensService().createSignerAuthenticationToken (nouveau PackageId(packageId), signId); jeton d'authentification à usage multiple
String singleUseToken - eslClient.getAuthenticationTokensService().createSignerAuthenticationTokenForSingleUse(packageId, signId, null); jeton d'authentification à usage unique

.Net SDK:

string signerAuthToken - eslClient.AuthenticationTokenService.CreateSignerAuthenticationToken (nouveau packageId(packageId), signId); jeton d'authentification à usage multiple
string singleUseToken - eslClient.AuthenticationTokensService.CreateSignerAuthenticationTokenForSingleUse (packageId, signId, signSessionFields); jeton d'authentification à usage unique

API REST

Demande HTTP
POST /api/authenticationTokens/signer/multiUse // pour usage multiple
POST /api/authenticationTokens/signer/singleUse // pour un usage unique
En-têtes HTTP
Accepter : application/json
Content-type: application/JSON
Autorisation: api_key de base
Demande de charge utile
{
    "packageId": "5vjLRY5MWrDJ6MzRAEyCKOy5IH0",
    "signerId": "8b734331-bc5b-4843-9784-d4ece4b7dc22"
}
Charge utile de réponse
{
   "packageId":"5vjLRY5MWrDJ6MzRAEyCKOy5IH0"
   "signerId":"8b734331-bc5b-4843-9784-d4ece4b7dc22",
   "valeur":"ZDNmMDNiNGUtNGYxOC00YWZiLTkwMmUtNWE5YmIwZTRjZDg1"
}

Chacune de ces méthodes donnera un jeton, comme celui ci-dessous, qui est composé de lettres de cas supérieurs et minuscules ainsi que des chiffres.

NDlkZjEyOWYtODFmY000NDI2LWJhNDYtZTVJMmE3ZGI1YjEy

Il est combiné avec le cas supérieur, le cas inférieur et le nombre.

Note:

1. L'ID de signataire dans cet appel SDK/API peut être remplacé par l'e-mail du signataire.

2. Le jeton d'authentification ne peut être généré que lorsque le paquet est en état "SENT" ou "COMPLETED".

3. Si vous avez modifié l'e-mail de votre signataire dans votre flux de travail, vous devrez générer un nouveau jeton d'authentification, car leur e-mail sera également validé lors de l'accès à la cérémonie de signature. Si cette validation échoue, le signataire sera redirigé vers une page qui ressemble à la capture d'écran ci-dessous:

Après avoir récupéré le jeton d'authentification, vous pouvez obtenir une session de signature en construisant l'URL suivante :

https://sandbox.esignlive.com/access?sessionToken-signerAuthToken

Signature url

Dans Java SDK, vous pouvez générer une URL de signature directement en utilisant cette fonction :

Signature de chaîneUrl - eslClient.getPackageService().getSigningUrl (nouveau PackageId("package id"), "signer Id"); dans ce cas, l'id signataire ne peut pas être remplacé par e-mail

Et dans .Net SDK:

signature de chaîneUrl - eslClient.PackageService.GetSigningUrl (nouveau packageId("package id"), "sign id"); dans ce cas, l'id signataire ne peut pas être remplacé par e-mail

Lorsque vous utilisez un SDK pour générer l'URL de signature, OneSpan Sign vous invite à utiliser l'ID de signataire au lieu d'un e-mail ou d'un ID de rôle. Ainsi, lors de la construction d'un objet signataire, une fonction avecCustomId() pour synchroniser l'ID de rôle et l'ID Designer est fortement recommandée.

Demande HTTP
GET /api/packages/'packageId/roles/'roleId/signingUrl
En-têtes HTTP
Accepter : application/json
Content-type: application/JSON
Autorisation: api_key de base
Charge utile de réponse
{
  "roleId": "2jsTTXD2dZMZ",
  %3"url": "https://sandbox.e-signlive.com/auth?target=https%2%2A F Fsandbox.esignlive.com-r'n%2Fpackages%2FnaXQwWFSQB9RkOiH6AguBCkXp2kAwGpGY3JJPS55ZnNSeHBmekNxc1RzdnNNJRVlBSDkZBR1RhcmxKS09aZ3M4aFZXVlpvdExrdz09",%2
  "packageId": "a3b023bf-db56-4c53-b36e-bd9acd0579f4"
}

Au repos

Cela diffère de la SDK parce que, cela nécessite un ID de rôle au lieu d'un ID Signer.

Note:

Semblable au jeton d'authentification, l'URL de signature est liée à un e-mail spécifique. Si vous modifiez l'e-mail de votre signataire, assurez-vous de réexécuter la fonction et de créer une nouvelle URL de signature.

Grâce à ce blog, nous avons démontré comment récupérer programmatiquement un jeton d'authentification et une URL de signature. Avec la première partie de ce blog,vous pouvez avoir plus de flexibilité dans vos choix lors du développement de jetons d’authentification.

Si vous avez des questions concernant ce blog ou toute autre chose concernant l'intégration de OneSpan Sign dans votre application, visitez les Forums communautairesdes développeurs . Vos commentaires sont importants pour nous!