Français

api-keys
personal-access-tokens
machine-to-machine
service-to-service
backend-to-backend
authentication
authorization
security
jwt
oauth2
rbac

Auth programmatique : clé API, jeton d'accès personnel et flux d'identification des informations d'identification client OAuth

Découvrez les concepts clés et les méthodes d'authentification programmatiques courantes, telles que la clé API, le jeton d'accès personnel (PAT) et les informations d'identification Machine-to-Machine (M2M) de Logto.

Charles

Developer

1/24/2024

Arrêtez de perdre des semaines sur l'authentification des utilisateurs

Lancez des applications sécurisées plus rapidement avec Logto. Intégrez l'authentification des utilisateurs en quelques minutes et concentrez-vous sur votre produit principal.

Commencer

Contexte

Dans le développement logiciel, lorsque nous devons accéder de manière programmée aux ressources API via des commandes CLI, ou établir une communication entre des services backend, il existe généralement trois mécanismes d'authentification largement utilisés par nous développeurs : clé API, Jeton d'accès personnel (PAT) et flux d'identification des informations d'identification client OAuth (marqué comme Machine-to-Machine dans Logto). Mais quelles sont les différences entre eux ? Quel est le scénario le mieux adapté à chacune de ces méthodes ? Dans cet article de blog, nous allons explorer les similitudes, les différences, et fournir des informations sur quand utiliser chacune d'elles dans différents scénarios.

Définitions

Clé API : Une simple chaîne qui peut authentifier votre requête vers une ressource API.
Jeton d'accès personnel (PAT) : Également une simple chaîne mais représente un utilisateur lorsqu'il est utilisé pour s'authentifier à une ressource API. C’est une délégation d'un utilisateur.
Logto Machine-to-Machine (Logto M2M) : Un flux standard d'identification des informations d'identification client OAuth, qui nécessite qu'un client soit enregistré au préalable, et nécessite l'utilisation de l'ID client et du secret pour échanger un jeton d'accès. Ainsi, l'identification Logto M2M représente un client de confiance et la nature du flux d'identification des informations d'identification client OAuth le rend relativement compliqué lors de son utilisation.

Similarités

1. But de l'authentification

Les trois, clé API, PAT, et Logto M2M, servent au but principal d'authentifier un utilisateur ou une application pour accéder à un service ou une ressource spécifique. Ils agissent comme des informations d'identification pour prouver l'identité du demandeur, et sont généralement utilisés dans des commandes CLI ou des scénarios de communication backend-to-backend.

2. Mesures de sécurité

Ces trois méthodes d'authentification doivent être traitées avec la sécurité à l'esprit. Les développeurs doivent assurer le stockage et la transmission sécurisés pour prévenir l'accès non autorisé.

Différences

1. Contexte utilisateur

La clé API n'identifie pas un principal, ni ne fournit d'informations d'autorisation. Par conséquent, les clés API sont souvent utilisées pour accéder à des données ou des ressources publiques de manière anonyme. Tous les services ne sont PAS pris en charge par l'utilisation de clés API.
Le PAT est une identité utilisateur et vous représentera lorsqu'il est utilisé pour demander une ressource API. Dans certains systèmes, les PAT ne sont pas autorisés à accéder à certains services. Par exemple, publier des packages NuGet sur le flux Azure Artifacts.
Les informations d'identification Logto M2M ne peuvent être utilisées que par des clients de confiance. Le client doit être enregistré au préalable pour être authentifié. Lors de l'utilisation des informations d'identification Logto M2M, cela représente le client de confiance au lieu de l'utilisateur qui l'utilise.

2. Granularité des permissions

Les PAT et les informations d'identification Logto M2M offrent généralement un contrôle plus granulaire sur les permissions par rapport à la clé API, permettant un contrôle fin sur quelles actions peuvent être effectuées.

3. Format du token

La clé API et le PAT sont généralement des chaînes opaques de type simple et simple.
Les jetons d'accès émis via le mécanisme Logto M2M sont généralement au format JWT.

4. Flux d'autorisation

La clé API et le PAT sont des chaînes opaques générées par le système, aucun flux d'authentification n’est impliqué pendant le processus. Par exemple, vous pouvez appeler l'API de langage naturel Google Cloud comme ceci :

Logto M2M utilise le flux standard d'identification des informations d'identification client OAuth 2.0. Chaque client doit obtenir une paire d'ID client et de secret client au préalable, avec lesquels le client peut échanger un jeton d'accès plus tard. Le client utilise ensuite le jeton d'accès pour accéder à la ressource API.

Quand utiliser chacun

Clé API

Communication service-à-service : Les clés API sont adaptées pour les scénarios où les applications doivent communiquer avec des API directement via des CLI. Par exemple, appeler les API d'OpenAI.
API publiques : Lors de l'exposition d'API au public, les clés API fournissent une méthode simple de contrôle d'accès.
Configuration simplifiée : Pour des besoins d'authentification rapide et simple, surtout en phase de développement. Contrairement à Logto M2M, les clés API ne nécessitent pas d'enregistrement client au préalable, et ne nécessitent pas d'échanger un jeton d'accès non plus. Vous passez simplement votre clé API en tant que paramètre dans votre requête et cela fonctionne simplement.

Jeton d'accès personnel (PAT)

Actions spécifiques à l'utilisateur : Lorsqu'une application a besoin d'effectuer des actions au nom d'un utilisateur.
Contrôle d'accès granulaire (utilisateur) : Lorsque un contrôle précis sur les actions qu'un utilisateur peut effectuer est requis.

Logto Machine-to-Machine (Logto M2M)

Sécurité : Logto M2M est idéal pour les scénarios où seuls les clients de confiance sont autorisés à accéder aux services backend.
Contrôle d'accès granulaire (client) : Lorsque un contrôle précis sur les actions qu'une application peut effectuer est requis.

Conclusion

En résumé, le choix entre les clés API, les PAT et Logto M2M dépend des exigences spécifiques de votre application, qu'elle implique des actions spécifiques à un utilisateur, une communication machine-to-machine, ou une combinaison des deux. Évaluez les besoins en matière de sécurité et de fonctionnalité pour déterminer la méthode d'authentification la plus appropriée pour votre cas d'utilisation.

Le mécanisme Logto M2M permet aux utilisateurs de définir des contrôles d'accès granulaires sur la fonction RBAC (contrôle d'accès basé sur les rôles). Nous prévoyons également de prendre en charge la clé API et le PAT dans un proche avenir. Restez à l'écoute de nos mises à jour de fonctionnalités !

Essayez Logto aujourd'hui

Contexte#

Définitions#

Similarités#

1. But de l'authentification#

2. Mesures de sécurité#

Différences#

1. Contexte utilisateur#

2. Granularité des permissions#

3. Format du token#

4. Flux d'autorisation#

Quand utiliser chacun#

Clé API#

Jeton d'accès personnel (PAT)#

Logto Machine-to-Machine (Logto M2M)#

Conclusion#

Contexte#

Définitions#

Similarités#

1. But de l'authentification#

2. Mesures de sécurité#

Différences#

1. Contexte utilisateur#

2. Granularité des permissions#

3. Format du token#

4. Flux d'autorisation#

Quand utiliser chacun#

Clé API#

Jeton d'accès personnel (PAT)#

Logto Machine-to-Machine (Logto M2M)#

Conclusion#

Contexte

Définitions

Similarités

1. But de l'authentification

2. Mesures de sécurité

Différences

1. Contexte utilisateur

2. Granularité des permissions

3. Format du token

4. Flux d'autorisation

Quand utiliser chacun

Clé API

Jeton d'accès personnel (PAT)

Logto Machine-to-Machine (Logto M2M)

Conclusion

Contexte

Définitions

Similarités

1. But de l'authentification

2. Mesures de sécurité

Différences

1. Contexte utilisateur

2. Granularité des permissions

3. Format du token

4. Flux d'autorisation

Quand utiliser chacun

Clé API

Jeton d'accès personnel (PAT)

Logto Machine-to-Machine (Logto M2M)

Conclusion