Identificare i token di accesso supportati

Completato

Qui vengono fornite informazioni sui diversi token di accesso di GitHub, sulle relative applicazioni, limitazioni e limiti di frequenza.

Quando si concede l'accesso agli utenti 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 utente-server di GitHub
• 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, quindi in Developer settings, selezionare Personal access tokens.

È possibile definire l'ambito di un singolo token per consentire solo l'accesso necessario per l'autenticazione del processo a cui è stato 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 problema di 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 dispositivo è sostanzialmente una versione di account macchina di un PAT, usata nel contesto di un dispositivo, che concede l'accesso a un repository specifico in casi d'uso particolari non associati a un utente. La configurazione di un'applicazione tramite un flusso OAuth usa un token del dispositivo. Vengono in genere usati con strumenti di esecuzione, servizi applicazioni speciali, processi Cron (in Linux) o altri scenari simili correlati alle attività automatizzate. Proprio come il token di accesso personale, il token del dispositivo è associato a un singolo account e l'account per cui si crea il token del 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 l'app GitHub a cui si applica il token nel repository di destinazione. I token di installazione sono validi per un'ora e sono sicuri perché vengono generati per uno scopo specifico e scadono in un periodo di tempo relativamente breve.

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 senza interfaccia, come ad esempio gli strumenti CLI. 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. Ad esempio, se si vuole usare un'app che richiede l'ambito user:email, all'app viene concesso l'accesso in sola lettura agli indirizzi di posta elettronica privati. Questi token possono essere acquisiti usando il flusso applicazione Web per applicazioni di produzione. Poiché questi token sono a breve termine e scadono in 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. Il prefisso inizia con due lettere che indicano l'azienda, gh, e viene seguito dalla prima lettera del tipo di token. I prefissi per i tipi di token di accesso disponibili 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, che consente di garantire che stringhe generate in modo casuale, ad esempio gli algoritmi di hash sicuri (SHA, Secure Hash Algorithms) non possano duplicare accidentalmente questi token. I prefissi contribuiscono anche a ridurre il tasso di falsi positivi nell'analisi dei segreti, una funzionalità avanzata di sicurezza di GitHub progettata per migliorare ulteriormente la protezione all'interno del repository 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 punto di strozzatura. 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.

È 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.