magic github proxy
1.0.0
Il s'agit d'un proxy d'API GitHub sans état qui permet la création et l'utilisation de jetons d'API GitHub à accès limité .
Fondamentalement, il s'agit de la gestion des identités et des accès pour les jetons de l'API GitHub.
Les jetons API de GitHub ne permettent pas un contrôle précis sur les actions qu'un jeton peut effectuer (voir ce problème Cher GitHub). Par exemple, vous devez essentiellement créer un jeton qui a un contrôle total sur un référentiel pour permettre à un jeton d'appliquer simplement des étiquettes aux problèmes.
C’est problématique à grande échelle. Lorsque de nombreuses tâches, processus et/ou robots interagissent avec l'API GitHub, vous augmentez la probabilité qu'un jeton soit compromis et les jetons dotés d'autorisations étendues ont des conséquences très élevées.
Ce proxy vous permet de créer des jetons API avec des autorisations précises (un jeton magique ), puis de communiquer avec l'API GitHub en utilisant ces jetons magiques via un proxy. Le proxy valide le jeton magique et permet d'effectuer l'action demandée, puis transmet la demande à l'API GitHub à l'aide du véritable jeton de l'API GitHub.
Ce proxy ne nécessite aucun stockage de sauvegarde et stocke tout son état dans le jeton magique lui-même.
Le proxy utilise une cryptographie asymétrique (une paire de clés publique et privée) et des JWT pour coder son état dans le jeton magique.
Chaque jeton magique est un simple JWT signé par la clé privée du proxy avec ces revendications :
{
"iat": 1541616032,
"exp": 1699296032,
"github_token": "[long encrypted key]",
"scopes": [
"GET /user",
"GET /repos/theacodes/nox/issues"
]
}
La revendication github_token est une version chiffrée du jeton brut de l'API GitHub. Il est chiffré à l'aide de la clé publique du proxy, afin que seul le proxy lui-même puisse le déchiffrer (à l'aide de sa clé privée ).
La revendication des portées détermine à quoi le jeton magique a accès. Ce proxy a une implémentation de portée basique et rudimentaire décrite ci-dessous, mais vous pouvez implémenter n'importe quelle stratégie de portée de votre choix.
Le JWT est généré et signé par le proxy lui-même à l'aide de sa clé privée . Cela signifie que le contenu ne peut pas être falsifié sans invalider le JWT.
Par défaut, ce proxy a une stratégie de portée simple utilisant le format :
METHOD /url/pattern
Où METHOD peut être GET , POST , PUT , etc. et /url/pattern peut être n'importe quelle expression régulière utilisée pour vérifier l'URL.
Par exemple, pour créer un jeton ayant accès aux problèmes de n'importe quel référentiel dans someorg , vous pouvez faire :
GET /repos/someorg/.+?/issues
FAIRE
Il ne s'agit pas d'un produit Google officiel, expérimental ou autre. Ce n’est pas une solution miracle pour la sécurité. Vous assumez tous les risques lors de l’utilisation de ce projet.
