Versions publiées

Les fonctionnalités et les modifications majeures apportées aux versions des déclencheurs du flux de connexion sont énumérées ci-dessous.

• api.redirect.canRedirect() est qualifié comme déconseillé.

• api.redirect.sendUserTo() n’ignorera plus la redirection lorsqu’il s’agit d’un flux non interactif. Cela signifie que les appels à api.redirect.sendUserTo() doivent d’abord vérifier si la redirection est nécessaire avant de l’effectuer. Des informations telles que event.authentication.methods peuvent être consultées pour vérifier si une redirection a été effectuée avec succès et enregistrée au moyen de api.authentication.recordMethod(). Une tentative de redirection dans un flux non interactif déclenchera bien une erreur interaction_required.

• event.authentication.methods peut désormais contenir des méthodes personnalisées réalisées par les utilisateurs au cours de cette séance et enregistrées à l’aide de api.authentication.recordMethod() dans le gestionnaire onContinuePostLogin.

• api.authentication.recordMethod() est ajoutée pour permettre de stocker un enregistrement de l’achèvement d’une méthode personnalisée dans la séance de l’utilisateur. Ces API vous permettent d’exiger des facteurs strictement personnalisés dans certains scénarios. L’utilisateur (sur un appareil particulier) devra effectuer le facteur personnalisé, qu’il y ait ou non une connexion interactive. Si les conditions sont réunies pour exiger le facteur personnalisé et que la session de l’utilisateur ne contient pas d’enregistrement de sa réalisation, l’interactivité du flux ne devrait pas influencer le fait qu’il soit exigé ou non. Voici un exemple de ce qu’il faut faire si vous souhaitez mettre en place un facteur personnalisé obligatoire :

  1. Dans onExecutePostLogin, recherchez un enregistrement dans le tableau event.authentication.methods avec l’URL d’identifiant de la méthode personnalisée. Si la méthode existe et que son horodatage est suffisamment récent, la connexion peut se poursuivre. Sinon, déclenchez une redirection vers l’URL d’implémentation du facteur personnalisé en utilisant api.redirect.sendUserTo(). Les données personnalisées peuvent être encodées dans un JWT et signées à l’aide de api.redirect.encodeToken().

  2. Lorsque l’utilisateur est redirigé vers /continue, le gestionnaire onContinuePostLogin est invoqué. Dans ce gestionnaire, validez les données renvoyées par le facteur personnalisé (si nécessaire) et signalez son achèvement en appelant api.authentication.recordMethod().

Dans la version du déclencheur post-connexion précédant la mise à disposition générale, les effets secondaires étaient exécutés en renvoyant un objet à partir d’une action. En ce qui concerne les actions mises à disposition générale, un objet api permet d’encapsuler ces changements et de fournir de meilleures suggestions dans l’éditeur ainsi qu’une documentation en ligne.

Mettre à jour user user_metadata

Déclencheur avant la mise à disposition générale :

async function myFunction(event, context) {
  return {
    user: {
      userMetadata: {
        myParam: "foo"
      }
    }
  };
}

Déclencheur après la mise à disposition générale :

async function onExecutePostLogin(event, api) {
  api.user.setUserMetadata('myParam', 'foo');
}

Mettre à jour user app_metadata

Déclencheur avant la mise à disposition générale :

async function myFunction(event, context) {
  return {
    user: {
      appMetadata: {
        myParam: "foo"
      }
    }
  };
}

Déclencheur après la mise à disposition générale :

async function onExecutePostLogin(event, api) {
  api.user.setAppMetadata('myParam', 'foo');
}

Refuser une connexion

Déclencheur avant la mise à disposition générale :

async function myFunction(event, context) {
  throw new Error("Access denied.");
}

Déclencheur après la mise à disposition générale :

async function onExecutePostLogin(event, api) {
  api.access.deny("Access denied.");
}

Ajouter des demandes personnalisées au jeton d’accès

Déclencheur avant la mise à disposition générale :

async function myFunc(event, context) {
  return {
    accessToken: {
      customClaims: {
        'https://example.com/custom/claim': 'Custom claim value',
      }
    }
  };
}

async function myFunc(event, api) {
  api.accessToken.setCustomClaim('https://example.com/custom/claim', 'Custom claim value');
}

Ajouter des demandes personnalisées au jeton d’ID

Déclencheur avant la mise à disposition générale :

async function myFunc(event, context) {
  return {
    idToken: {
      customClaims: {
        'https://example.com/custom/claim': 'Custom claim value',
      }
    }
  };
}

Déclencheur après la mise à disposition générale :

async function myFunc(event, api) {
  api.idToken.setCustomClaim('https://example.com/custom/claim', 'Custom claim value');
}

Activer l’authentification multifacteur (MFA) de façon dynamique

Déclencheur avant la mise à disposition générale :

async function myFunction(event, context) {
  return {
    command: {
      type: "multifactor",
      provider: "any"
    }
  };
}

Déclencheur après la mise à disposition générale :

async function onExecutePostLogin(event, api) {
  api.multifactor.enable("duo");
}

Rediriger l’utilisateur

Déclencheur avant la mise à disposition générale :

async function myFunction(event, context) {
  return {
    command: {
      type: "redirect",
      url: "https://my-app.example.com"
    }
  };
}

Déclencheur après la mise à disposition générale :

async function onExecutePostLogin(event, api) {
  api.redirect.sendUserTo("https://my-app.example.com");
}

Afin de garantir que les paramètres sont envoyés en toute sécurité et d’éviter les attaques par réinsertion, la transmission de données via des redirections a été considérablement modifiée dans Actions Disponibilité générale. Pour plus de détails, consultez Rediriger avec des actions.

Bien que nous ayons testé la manipulation directe des permissions de jeton d’ID et d’accès dans la version bêta des actions, nous ne prenons pas en charge cette fonctionnalité dans la version finale.