Passer au contenu principal
Vous pouvez ajouter la connexion à votre application native, mobile ou monopage à l’aide du flux de code d’autorisation avec PKCE. Pour savoir comment ce flux fonctionne et pourquoi vous devriez l’utiliser, consultez Flux de code d’autorisation avec Proof Key for Code Exchange (PKCE). Pour savoir comment appeler votre API à partir d’une application native, mobile ou monopage, consultez Appeler votre API à l’aide du flux de code d’autorisation avec PKCE. Pour implémenter le flux de code d’autorisation avec Proof Key for Code Exchange (PKCE), vous pouvez utiliser les ressources suivantes : Après une connexion réussie, votre application aura accès au et au de l’utilisateur. Le jeton d’identité contiendra les renseignements de base du profil utilisateur, et le jeton d’accès peut servir à appeler le point de terminaison /userinfo d’Auth0 ou vos propres API protégées. Pour en savoir plus sur les ID tokens, consultez ID Tokens. Pour en savoir plus sur les jetons d’accès, consultez Access Tokens.

Prérequis

Enregistrez votre application dans Auth0. Pour en savoir plus, consultez Enregistrer des applications natives ou Enregistrer des applications Web monopages.
  • Sélectionnez un Type d’application de Native ou Application monopage, selon le type de votre application.
  • Ajoutez YOUR_CALLBACK_URL comme URL de rappel autorisée. Le format de votre URL de rappel varie selon le type et la plateforme de votre application. Pour plus de détails sur le format correspondant à votre type d’application et à votre plateforme, consultez nos guides de démarrage rapide Native/Mobile et guides de démarrage rapide Application monopage.
  • Assurez-vous que les Types d’octroi de votre application incluent Code d’autorisation. Pour en savoir plus, consultez Mettre à jour les types d’octroi.

Créer le vérificateur de code

Créez un code_verifier, c’est-à-dire une clé aléatoire cryptographiquement sécurisée, encodée en Base64, qui sera ensuite envoyée à Auth0 pour demander des jetons. Pour en savoir plus sur l’algorithme utilisé pour créer le code_verifier, consultez la section 4.1 Client Creates a Code Verifier de la spécification Proof Key for Code Exchange.

Exemple en JavaScript

// Dépendance : module crypto de Node.js
// https://nodejs.org/api/crypto.html#crypto_crypto
function base64URLEncode(str) {
    return str.toString('base64')
        .replace(/\+/g, '-')
        .replace(/\//g, '_')
        .replace(/=/g, '');
}
var verifier = base64URLEncode(crypto.randomBytes(32));

Exemple en Java

// Dépendance : Apache Commons Codec
// https://commons.apache.org/proper/commons-codec/
// Importer la classe Base64.
// import org.apache.commons.codec.binary.Base64;
SecureRandom sr = new SecureRandom();
byte[] code = new byte[32];
sr.nextBytes(code);
String verifier = Base64.getUrlEncoder().withoutPadding().encodeToString(code);

Exemple pour Android

// Dépendance : Apache Commons Codec
// https://commons.apache.org/proper/commons-codec/
// Importer la classe Base64.
// import org.apache.commons.codec.binary.Base64;
SecureRandom sr = new SecureRandom();
byte[] code = new byte[32];
sr.nextBytes(code);
String verifier = Base64.encodeToString(code, Base64.URL_SAFE | Base64.NO_WRAP | Base64.NO_PADDING);

Exemple en Swift 5

var buffer = [UInt8](repeating: 0, count: 32)
_ = SecRandomCopyBytes(kSecRandomDefault, buffer.count, &buffer)
let verifier = Data(buffer).base64EncodedString()
    .replacingOccurrences(of: "+", with: "-")
    .replacingOccurrences(of: "/", with: "_")
    .replacingOccurrences(of: "=", with: "")

Exemple en Objective-C

NSMutableData *data = [NSMutableData dataWithLength:32];
int result __attribute__((unused)) = SecRandomCopyBytes(kSecRandomDefault, 32, data.mutableBytes);
NSString *verifier = [[[[data base64EncodedStringWithOptions:0]
                        stringByReplacingOccurrencesOfString:@"+" withString:@"-"]
                        stringByReplacingOccurrencesOfString:@"/" withString:@"_"]
                        stringByTrimmingCharactersInSet:[NSCharacterSet characterSetWithCharactersInString:@"="]];

Créer le code challenge

Générez un code_challenge à partir du code_verifier, qui sera envoyé à Auth0 pour demander un authorization_code. Pour en savoir plus sur la façon dont le code_challenge est généré à partir du code_verifier, consultez la section 4.2 Le client crée le code challenge de la spécification OAuth Proof Key for Code Exchange.

Exemple en JavaScript

// Dépendance : module crypto de Node.js
// https://nodejs.org/api/crypto.html#crypto_crypto
function sha256(buffer) {
    return crypto.createHash('sha256').update(buffer).digest();
}
var challenge = base64URLEncode(sha256(verifier));

Exemple en Java

// Dépendance : Apache Commons Codec
// https://commons.apache.org/proper/commons-codec/
// Importer la classe Base64.
// import org.apache.commons.codec.binary.Base64;
byte[] bytes = verifier.getBytes("US-ASCII");
MessageDigest md = MessageDigest.getInstance("SHA-256");
md.update(bytes, 0, bytes.length);
byte[] digest = md.digest();
String challenge = Base64.encodeBase64URLSafeString(digest);

Exemple en Swift 5

import CommonCrypto

// ...

guard let data = verifier.data(using: .utf8) else { return nil }
var buffer = [UInt8](repeating: 0, count: Int(CC_SHA256_DIGEST_LENGTH))
_ = data.withUnsafeBytes {
    CC_SHA256($0.baseAddress, CC_LONG(data.count), &buffer)
}
let hash = Data(buffer)
let challenge = hash.base64EncodedString()
    .replacingOccurrences(of: "+", with: "-")
    .replacingOccurrences(of: "/", with: "_")
    .replacingOccurrences(of: "=", with: "")

Exemple en Objective-C

// Dépendance : bibliothèque Apple Common Crypto
// http://opensource.apple.com//source/CommonCrypto
u_int8_t buffer[CC_SHA256_DIGEST_LENGTH * sizeof(u_int8_t)];
memset(buffer, 0x0, CC_SHA256_DIGEST_LENGTH);
NSData *data = [verifier dataUsingEncoding:NSUTF8StringEncoding];
CC_SHA256([data bytes], (CC_LONG)[data length], buffer);
NSData *hash = [NSData dataWithBytes:buffer length:CC_SHA256_DIGEST_LENGTH];
NSString *challenge = [[[[hash base64EncodedStringWithOptions:0]
                         stringByReplacingOccurrencesOfString:@"+" withString:@"-"]
                         stringByReplacingOccurrencesOfString:@"/" withString:@"_"]
                         stringByTrimmingCharactersInSet:[NSCharacterSet characterSetWithCharactersInString:@"="]];

Autoriser l’utilisateur

Demandez l’autorisation de l’utilisateur et redirigez-le vers votre application avec un authorization_code. Une fois le code_verifier et le code_challenge créés, vous devez obtenir l’autorisation de l’utilisateur. Techniquement, c’est le début du , et cette étape peut comprendre un ou plusieurs des processus suivants :
  • Authentifier l’utilisateur;
  • Rediriger l’utilisateur vers un pour prendre en charge l’authentification;
  • Vérifier s’il existe des sessions d’authentification unique (SSO) actives;
  • Obtenir le consentement de l’utilisateur pour le niveau d’autorisation demandé, sauf s’il a déjà été accordé.
Pour autoriser l’utilisateur, votre application doit le rediriger vers l’URL d’autorisation, en incluant le code_challenge généré à l’étape précédente ainsi que la méthode utilisée pour le générer.

Exemple d’URL d’autorisation

Paramètres

Parameter NameDescription
response_typeIndique le type d’identifiant qu’Auth0 renverra (code ou token). Pour ce flux, la valeur doit être code.
code_challengeDéfi généré à partir du code_verifier.
code_challenge_methodMéthode utilisée pour générer le défi (par ex. S256). La spécification PKCE définit deux méthodes, S256 et plain ; la première est utilisée dans cet exemple et c’est la seule qu’Auth0 prend en charge, puisque la seconde est déconseillée.
client_idL’ID client de votre application. Vous trouverez cette valeur dans vos paramètres de l’application.
redirect_uriL’URL vers laquelle Auth0 redirigera le navigateur une fois l’autorisation accordée par l’utilisateur. Le code d’autorisation sera disponible dans le paramètre d’URL code. Vous devez indiquer cette URL comme URL de rappel valide dans vos paramètres de l’application.

Avertissement : Conformément à la spécification OAuth 2.0, Auth0 supprime tout ce qui suit le hash et ignore les fragments.
scopePrécise les scopes pour lesquels vous souhaitez demander une autorisation, ce qui détermine quelles claims (ou quels attributs utilisateur) vous voulez voir renvoyés. Ils doivent être séparés par un espace. Pour obtenir un ID Token dans la réponse, vous devez préciser au minimum le scope openid. Si vous souhaitez renvoyer le profil complet de l’utilisateur, vous pouvez demander openid profile. Vous pouvez demander n’importe lequel des scopes OpenID Connect (OIDC) standard concernant les utilisateurs, comme email, ou des custom claims conformes à un format avec espace de noms. Incluez offline_access pour obtenir un Jeton d’actualisation (assurez-vous que le champ Allow Offline Access est activé dans les paramètres de l’application).
state(recommandé) Chaîne alphanumérique arbitraire et opaque que votre application ajoute à la requête initiale et qu’Auth0 inclut lors de la redirection vers votre application. Pour savoir comment utiliser cette valeur afin de prévenir les attaques de falsification de requête intersites (CSRF), consultez Mitigate CSRF Attacks With State Parameters.
connection(facultatif) Force l’utilisateur à se connecter avec une connexion précise. Par exemple, vous pouvez transmettre la valeur github pour envoyer directement l’utilisateur vers GitHub afin qu’il se connecte avec son compte GitHub. Lorsqu’elle n’est pas précisée, l’utilisateur voit l’écran Auth0 Lock avec toutes les connexions configurées. Vous pouvez voir la liste de vos connexions configurées dans l’onglet Connections de votre application.
organization(facultatif) ID de l’organisation à utiliser lors de l’authentification d’un utilisateur. Lorsqu’il n’est pas fourni, si votre application est configurée pour Display Organization Prompt, l’utilisateur pourra saisir le nom de l’organisation au moment de l’authentification.
invitation(facultatif) ID du ticket d’invitation de l’organisation. Lorsque vous invitez un membre à une Organisation, votre application doit gérer l’acceptation de l’invitation en transmettant les paires clé-valeur invitation et organization lorsque l’utilisateur accepte l’invitation.
Par exemple, votre extrait HTML pour votre URL d’autorisation lors de l’ajout de la connexion à votre application pourrait ressembler à ceci :

Réponse

Si tout se passe bien, vous recevrez une réponse HTTP 302. Le code d’autorisation est inclus à la fin de l’URL :
HTTP/1.1 302 Found
Location: {yourCallbackUrl}?code={authorizationCode}&state=xyzABC123

Obtenir des jetons

Échangez votre authorization_code et votre code_verifier contre des jetons. Maintenant que vous avez un code d’autorisation, vous devez l’échanger contre des jetons. À l’aide du code d’autorisation extrait (code) à l’étape précédente, vous devrez envoyer une requête POST à l’URL du jeton avec le code_verifier.

Exemple de requête POST vers l’URL du jeton

Paramètres

Nom du paramètreDescription
grant_typeDéfinissez cette valeur sur “authorization_code”.
code_verifierLa clé aléatoire générée de manière cryptographiquement sûre à la première étape de ce tutoriel.
codeLe authorization_code récupéré à l’étape précédente de ce tutoriel.
client_idL’ID client de votre application. Vous trouverez cette valeur dans les paramètres de l’application.
redirect_uriL’URL de rappel valide configurée dans les paramètres de votre application. Elle doit correspondre exactement au redirect_uri transmis à l’URL d’autorisation à l’étape précédente de ce tutoriel. Notez qu’elle doit être encodée au format URL.

Réponse

Si tout se passe bien, vous recevrez une réponse HTTP 200 avec un payload qui contient les valeurs access_token, refresh_token, id_token et token_type :
{
  "access_token":"eyJz93a...k4laUWw",
  "refresh_token":"GEbRxBN...edjnXbL",
  "id_token":"eyJ0XAi...4faeEoQ",
  "token_type":"Bearer",
  "expires_in":86400
}
Validez vos jetons avant de les enregistrer. Pour savoir comment faire, consultez Valider les ID Tokens et Valider les jetons d’accès.
Les ID tokens contiennent des informations sur l’utilisateur qui doivent être décodées et extraites. Les jetons d’accès servent à appeler l’endpoint /userinfo de l’Auth0 Authentication API ou une autre API. Si vous appelez votre propre API, la première chose qu’elle devra faire sera de vérifier le jeton d’accès. Les jetons d’actualisation servent à obtenir un nouveau jeton d’accès ou un jeton d’identité après l’expiration du précédent. Le refresh_token ne sera présent dans la réponse que si vous avez inclus le scope offline_access et activé Allow Offline Access pour votre API dans l’Auth0 Dashboard.
Les jetons d’actualisation doivent être stockés de façon sécurisée, car ils permettent à un utilisateur de rester authentifié pratiquement indéfiniment.

Cas d’utilisation

Requête d’authentification de base

Cet exemple montre la requête la plus élémentaire que vous pouvez effectuer lors de l’autorisation de l’utilisateur à l’étape 1. Il affiche l’écran de connexion d’Auth0 et permet à l’utilisateur de se connecter à l’aide de n’importe laquelle de vos connexions configurées : Maintenant, lorsque vous demanderez des jetons, votre ID Token contiendra les claims de base. Lorsque vous décoderez l’ID Token, il ressemblera à ceci :
{
  "iss": "https://auth0pnp.auth0.com/",
  "sub": "auth0|581...",
  "aud": "xvt9...",
  "exp": 1478112929,
  "iat": 1478076929
}

Demander le nom et la photo de profil de l’utilisateur

En plus de l’authentification standard de l’utilisateur, cet exemple montre comment demander des renseignements supplémentaires, comme son nom et sa photo. Pour demander le nom et la photo de l’utilisateur, vous devez ajouter les scopes appropriés lorsque vous autorisez l’utilisateur : Désormais, lorsque vous demanderez des jetons, votre jeton d’identité contiendra les claims name et picture demandées. Lorsque vous décoderez le jeton d’identité, il ressemblera à ceci :
{
  "name": "auth0user@...",
  "picture": "https://example.com/profile-pic.png",
  "iss": "https://auth0user.auth0.com/",
  "sub": "auth0|581...",
  "aud": "xvt...",
  "exp": 1478113129,
  "iat": 1478077129
}

Demander à l’utilisateur de se connecter avec GitHub

En plus de l’authentification habituelle des utilisateurs, cet exemple montre comment rediriger les utilisateurs directement vers un fournisseur d’identité social, comme GitHub. Pour que cet exemple fonctionne, vous devez aller à Auth0 Dashboard > Authentification > Social et configurer la connexion appropriée. Relevez le nom de la connexion dans l’onglet Settings. Pour envoyer les utilisateurs directement à l’écran de connexion de GitHub, vous devez transmettre le paramètre connection et définir sa valeur sur le nom de la connexion (dans ce cas, github) au moment d’autoriser l’utilisateur : Désormais, lorsque vous demanderez des jetons, votre jeton d’identité contiendra une revendication sub avec l’identifiant unique de l’utilisateur renvoyé par GitHub. Lorsque vous décoderez le jeton d’identité, il ressemblera à ceci :
{
  "name": "John Smith",
  "picture": "https://avatars.example.com",
  "email": "jsmith@...",
  "email_verified": true,
  "iss": "https://auth0user.auth0.com/",
  "sub": "github|100...",
  "aud": "xvt...",
  "exp": 1478114742,
  "iat": 1478078742
}

En savoir plus