Identificare i token di accesso supportati

  • 8 minuti

Verranno fornite informazioni sui diversi token di accesso di GitHub, le rispettive applicazioni, le limitazioni e i limiti di frequenza.

Quando si tratta di concedere l'accesso a un utente all'interno dell'azienda, l'autenticazione è estremamente importante. L'accesso utente deve avere un ambito limitato e includere solo gli elementi necessari per completare le attività. La comprensione dei diversi token di accesso è importante perché consente agli utenti nell'azienda di usare l'opzione migliore per i casi d'uso specifici.

GitHub usa vari token che consentono agli utenti di eseguire l'autenticazione alle diverse attività che devono eseguire. In genere, questi diversi token sono semplici da usare ed è facile sapere quale token usare. A volte è tuttavia possibile usare più token per ottenere lo stesso risultato, quindi potrebbe essere necessario scegliere tra un token appropriato, più appropriato o migliore. In queste situazioni è importante identificare le caratteristiche dei token di GitHub e come impostare correttamente l'ambito di accesso di un token. Di seguito è riportato un elenco dei diversi token di accesso disponibili:

  • Token di accesso personali di GitHub
  • Token GitHub da utente a server
  • Token GitHub da server a server
  • Token di accesso OAuth
  • Token di aggiornamento

È importante incoraggiare il team di sviluppo a usare i token con l'ambito giusto in modo che quando viene individuata una vulnerabilità di sicurezza, il rischio possa essere attenuato rapidamente. È ora possibile esaminare ogni tipo di token di accesso.

Token di accesso personali

Un token di accesso personale è un'alternativa all'uso di una password per l'autenticazione in GitHub. Per eseguire il push e il pull nei repository, GitHub deve verificare l'accesso utente. La verifica viene eseguita tramite l'indirizzo e-mail verificato di un utente. È possibile creare tutti i token di accesso personali necessari per il flusso di lavoro e tali token devono essere gestiti con lo stesso livello di sicurezza applicato per le password. La procedura consigliata per la sicurezza prevede l'uso di token diversi per applicazioni diverse. Per creare un token di accesso personale in GitHub, passare a Settings e in Developer settings si troveranno i Personal access tokens.

Screenshot con un esempio di token di accesso personale di GitHub.

È possibile limitare l'ambito di un singolo token solo all'accesso necessario per autenticare il processo a cui verrà assegnato. Il token è associato a un utente specifico e si allinea con il livello di accesso dell'utente per l'organizzazione e i repository. È possibile revocare un token di accesso personale in qualsiasi momento. Ciò è particolarmente importante se si verifica un attacco alla sicurezza. È importante comunicare al team che i token di accesso personali devono essere considerati in modo sicuro come un nome utente e una password. Se un token viene compromesso, è necessario intervenire immediatamente per revocare il token.

Per passaggi dettagliati per la creazione di un token di accesso personale, vedere Creazione di un token di accesso personale - GitHub Docs

Token di dispositivo

Un token di dispositivo è fondamentalmente una versione dell'account computer di un token di accesso personale, usata nel contesto di un dispositivo, che consente l'accesso a un repository specifico in casi d'uso specifici non associati all'utente. La configurazione di un'applicazione tramite un flusso OAuth usa un token del dispositivo. Vengono in genere usati con strumenti di esecuzione, servizi speciali dell'applicazione, processi Cron (in Linux) o altri scenari simili correlati alle attività automatizzate. Analogamente al token di accesso personale, è associato a un singolo account e l'account per cui si crea il token di dispositivo utilizza una licenza.

Token di installazione dell'applicazione GitHub

Un token di installazione consente a un'app GitHub di effettuare richieste API autenticate per l'installazione dell'applicazione in un'organizzazione. Prima di creare un token di installazione, è necessario installare nel repository di destinazione l'app GitHub a cui verrà applicato il token. I token di installazione sono validi per un'ora e, poiché vengono generati per uno scopo specifico e scadono in un periodo di tempo relativamente breve, sono sicuri.

Token di accesso OAuth

I token OAuth2 vengono usati per autorizzare gli utenti per le app OAuth standard eseguite nel browser e per le app headless, ad esempio gli strumenti dell'interfaccia della riga di comando. Consentono all'app di accedere all'API con un token di accesso utente. Questi token consentono di connettere l'identità utente di GitHub ad applicazioni di terze parti, permettendo all'app di eseguire azioni per conto dell'utente. Se ad esempio si vuole usare un'app che richiede l'ambito user:email, l'app avrà accesso in sola lettura agli indirizzi e-mail privati. Questi token possono essere acquisiti usando il flusso applicazione Web per applicazioni di produzione. Poiché questi token sono a breve termine e scadono entro 10 minuti, sono anche sicuri.

Token di aggiornamento

Un token di aggiornamento è connesso con un token OAuth. Quando viene concesso un nuovo token OAuth (tramite una richiesta da utente a server), nella risposta viene incluso un token di aggiornamento. Quando il token utente scade, il token di aggiornamento può essere scambiato con un nuovo token utente con una richiesta di callback. Ogni volta che viene rilasciato un nuovo token OAuth, viene incluso un token di aggiornamento. I token di aggiornamento sono validi per sei mesi e sono un buon promemoria per aggiornare i token OAuth.

Prefissi identificabili

Come si può notare nell'intero settore, i prefissi di token sono un modo chiaro per rendere identificabili i token. GitHub include prefissi di tre lettere per rappresentare ogni token, a partire da un significatore aziendale, gh, seguito dalla prima lettera del tipo di token. I risultati per i tipi di token precedenti sono:

  • ghp per token di accesso personali di GitHub
  • ghu per token GitHub da utente a server
  • ghs per token GitHub da server a server
  • gho per token di accesso OAuth
  • ghr per token di aggiornamento

Questi prefissi includono inoltre un separatore (_) all'interno del token per migliorare la leggibilità. Un carattere di sottolineatura non è un carattere Base64 e ciò consente di assicurarsi che questi token non vengano accidentalmente duplicati da stringhe generate in modo casuale come gli SHA. Questi prefissi consentono anche di ridurre il tasso di falsi positivi per l'analisi dei segreti, che è una funzionalità di GitHub Advanced Security per migliorare ulteriormente la sicurezza all'interno del repository di GitHub.

Limiti di frequenza dei token

Il superamento dei limiti di frequenza può causare la perdita di tempo di sviluppo. È ora possibile esaminare i limiti di frequenza per app GitHub e app OAuth. La comprensione dei limiti di frequenza consente di supportare gli sviluppatori nel team, contribuendo a ottimizzare gli investimenti dell'organizzazione in queste risorse di GitHub.

I limiti di frequenza consentono di controllare la frequenza del traffico su GitHub e si basano sulle richieste all'ora.

  • Un'app GitHub installata in un account GitHub Enterprise ha un limite di frequenza per le richieste pari a 15.000 richieste all'ora.
  • Un'app OAuth viene autenticata per un singolo utente ed è limitata a 5.000 richieste all'ora.

Per gli amministratori Enterprise, è consigliabile monitorare i limiti di frequenza delle app e collaborare con gli sviluppatori per modificare gli script in modo che non superino i limiti. I limiti di frequenza non costituiscono in genere un problema fino a quando lo sviluppatore non esegue operazioni come la scrittura di uno script che richiede troppe informazioni in un flusso di lavoro. Lo sviluppo si interrompe improvvisamente e i limiti di frequenza diventano un collo di bottiglia. Questi problemi di superamento del limite di frequenza possono essere evitati limitando il numero di richieste all'ora o modificando un flusso di lavoro in modo che attenda tra le richieste. Se si supera il limite di frequenza usando l'autenticazione di base oppure OAuth, è probabile che sia possibile risolvere il problema memorizzando nella cache le risposte dell'API e usando le richieste condizionali.

Dalla console di gestione è possibile configurare un limite di frequenza personalizzato per gli utenti non autenticati nell'organizzazione e creare un elenco di esenzioni che consenta a determinati utenti di usare il limite di frequenza completo dell'API.

Screenshot della console di gestione che imposta i limiti di frequenza dell'API.

È possibile controllare lo stato del limite di frequenza corrente in qualsiasi momento usando l'API Rate Limit illustrata di seguito. Le intestazioni HTTP restituite di qualsiasi richiesta API mostrano lo stato del limite di frequenza corrente.

curl \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/rate_limit

Esempio di risposta

{
  "resources": {
    "core": {
      "limit": 5000,
      "remaining": 4999,
      "reset": 1372700873,
      "used": 1
    },
    "search": {
      "limit": 30,
      "remaining": 18,
      "reset": 1372697452,
      "used": 12
    },
    "graphql": {
      "limit": 5000,
      "remaining": 4993,
      "reset": 1372700389,
      "used": 7
    },
    "integration_manifest": {
      "limit": 5000,
      "remaining": 4999,
      "reset": 1551806725,
      "used": 1
    },
    "code_scanning_upload": {
      "limit": 500,
      "remaining": 499,
      "reset": 1551806725,
      "used": 1
    }
  },
  "rate": {
    "limit": 5000,
    "remaining": 4999,
    "reset": 1372700873,
    "used": 1
  }
}

Per informazioni più dettagliate sui limiti di frequenza, vedere Limitazione della frequenza in GitHub Docs.