Lorsque je travaillais sur un système publicitaire, j'ai constaté que les systèmes publicitaires de la plupart des plateformes auxquelles je me connectais utilisaient des tokens pour autoriser les interfaces, et ce token restait inchangé et était fourni par les annonceurs. est une interface en séquences. Cependant, cette interface n'a pas d'exigences de sécurité élevées. Elle peut uniquement empêcher les appels malveillants et vérifier l'identité du canal.
L'année dernière, l'auteur a écrit une plate-forme d'autorisation unifiée API, qui fournit une gestion unifiée des autorisations pour les interfaces ouvertes de service interne et les appels système tiers, en plus de faciliter l'autorisation de l'interface de gestion, elle n'a aucun autre objectif, mais cela coûte de l'argent à déployer. C'est probablement le projet le plus inutile que j'ai jamais réalisé.
Le mécanisme d'autorisation API introduit aujourd'hui peut également être un mécanisme d'autorisation d'interface API plus largement utilisé. Je me souviens que lorsque l'auteur effectuait la fonction de paiement WeChat, l'interface de paiement fournie par WeChat utilisait également cette méthode. : signature. Avantages : Simple, sans impact sur les performances, sans surcoût.
La logique de mise en œuvre de cette méthode d'autorisation est que l'autorisateur définit une identité unique (clé) et une clé indépendante pour chaque plateforme d'accès, qui équivaut en fait à un mot de passe de compte. Le système d'accès doit contenir trois paramètres dans l'en-tête de la demande à chaque fois qu'il lance une demande, à savoir l'identité (clé), l'horodatage de la demande et la signature. Le système autorisant vérifie la signature lors de la réception de la demande. ne sera libéré que s’il réussit.
Le processus de vérification de la signature consiste à obtenir la clé et l'horodatage de l'en-tête de la requête, puis à générer une signature basée sur la clé en utilisant le même algorithme (l'appelant et l'autorisateur utilisent le même algorithme de signature) , et enfin comparez l'en-tête de la requête pour obtenir Si les signatures sont égales, si c'est le cas, la vérification est réussie, sinon la vérification échoue.
Le processus de mise en œuvre de la méthode d'autorisation basée sur l'algorithme de signature est le suivant :
Autorisant :
#🎜🎜 #1. Définir l'algorithme de signature, fournir l'algorithme de génération de signature à la partie d'accès et générer la clé et l'identité de la partie d'accès ;2. projet, et obtenez l'horodatage et l'identité de l'en-tête de la demande Identité, générez une signature basée sur l'algorithme de clé et de signature, comparez la signature générée avec la signature obtenue à partir de l'en-tête de la demande, si elles sont identiques, passez à l'étape 3, sinon rejeter la demande ; 3. Contrôle de la rapidité de la demande Pour vérification, comparez l'horodatage actuel du système avec l'horodatage obtenu à partir de l'en-tête de la demande. Si la demande se situe dans la plage de temps valide, la demande sera libérée. sinon, il sera rejeté et la signature sera expirée.Partie d'accès :
1. Obtenez le document d'amarrage auprès de la personne autorisée et demandez à la personne autorisée la clé et l'identité ;# 🎜 🎜#2. Encapsulez la méthode de signature selon l'algorithme de génération de signature fourni dans le document ;
3 Lorsque vous lancez une demande, écrivez l'identité, l'horodatage actuel et la signature dans le fichier. en-tête de requête.
L'algorithme de génération de signature peut être personnalisé. Par exemple, après avoir épissé l'identité (clé), l'horodatage (horodatage) et la clé, un algorithme irréversible est utilisé pour crypter la chaîne afin de générer une telle signature. comme algorithme MD5. Plus les règles sont complexes, plus il est difficile de les contourner.
Quels sont les avantages d'ajouter un horodatage à une signature
Le premier est d'ajouter de la rapidité à la signature ? Le système d'autorisation peut limiter la durée de validité de la signature à une ou cinq secondes, en utilisant l'horodatage de la demande pour comparer avec l'horodatage actuel. Cependant, l'heure système des deux parties doit être correcte.
La deuxième est la sécurité. Si un pirate informatique intercepte la requête de votre système, puis modifie la requête puis initie la requête, cela prendra certainement du temps, donc lorsque le système recevra la requête falsifiée, la signature La période de validité est passée. Si vous modifiez l'horodatage transmis dans l'en-tête de la demande, le système d'autorisation de la demande générera une signature différente de celle transmise dans l'en-tête de la demande, la demande sera donc toujours invalide.
Si vous ne connaissez pas la clé, vous ne pouvez pas générer une signature valide sans connaître les règles de signature de la partie autorisée (poulet de chair). Les fichiers signés à l’aide d’un algorithme de chiffrement asymétrique rendent presque impossible le déchiffrement de la clé par force brute.
Alors pourquoi utiliser l'horodatage au lieu de formater la chaîne horaire
Cela peut être dû à la compatibilité des fuseaux horaires. Si différentes salles informatiques se trouvent dans des fuseaux horaires différents, l'heure sera différente. . , mais les horodatages sont les mêmes.
Afin de maximiser la sécurité de cette méthode d'autorisation, tout d'abord, les règles de génération des signatures doivent être suffisamment complexes, ensuite l'algorithme de chiffrement de la signature doit être irréversible, ne jamais utiliser un algorithme comme Base64 , et enfin la clé. Elle doit être suffisamment longue et complexe pour garantir que même si les règles de génération de signature sont connues, il est impossible de forcer brutalement la clé.
Les règles de signature font référence aux règles de génération de chaînes de signature avant le chiffrement. Par exemple : les règles incluent la clé, la clé secrète et l'horodatage, où la clé et la clé apparaîtront deux fois. Supposons que la clé est "app", la clé secrète est "123", l'horodatage est "1111111111111", la signature pré-cryptée générée par l'épissage est "app1231111111111111app123", et enfin la chaîne épissée est cryptée via l'algorithme de cryptage pour générer la signature finale.
N'est-il pas gênant d'écrire la logique de signature pour chaque interface
Non. Pour l'autorisateur, la logique de vérification de la signature peut être complétée par des filtres ou des intercepteurs ; pour l'appelant, il existe différentes méthodes utilisant différents frameworks, mais on peut toujours trouver un moyen de n'écrire la logique de signature qu'une seule fois, non ?
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!