Configurare e utilizzare le applicazioni OAuth 2 personalizzate della tua organizzazione utilizzando il flusso PKCE
PKCE è un flusso di autorizzazione sicuro che funziona bene con le applicazioni di aggiornamento dinamico come le app mobili, ma è prezioso per tutti i client OAuth2. Invece di un segreto client statico, PKCE utilizza una stringa generata dinamicamente, eliminando il rischio di perdita di un segreto client.
Panoramica di PKCE
Un flusso PKCE prevede i seguenti passaggi. I passaggi descritti in questa sezione sono riportati a titolo puramente informativo. Per eseguire queste procedure, vedere altre sezioni in questo articolo.
-
Il client crea
code_challenge
trasformando ilcode_verifier
utilizzoS256
crittografia. -
Il client indirizza il browser alla pagina di accesso OAuth2, insieme al
code_challenge
. È necessario registrare l'app (Client) in modo che OAuth2 possa accettare la richiesta di autorizzazione. Dopo la registrazione, l’app può reindirizzare il browser a OAuth2. -
Il server di autorizzazione OAuth2 reindirizza la richiesta di autenticazione all'utente.
-
L’utente si autentica utilizzando una delle opzioni di accesso configurate e potrebbe visualizzare una pagina di consenso in cui sono elencate le autorizzazioni che OAuth2 concederà all’applicazione.
-
OAuth2 reindirizza all'applicazione con un
authorization code
. -
L'applicazione invia questo codice, insieme a
code_verifier
, a OAuth2. -
Il server di autorizzazione OAuth2 trasforma il
code_verifier
utilizzandocode_challenge_method
dalla richiesta di autorizzazione iniziale e verifica il risultato rispetto alcode_challenge
. Se il valore di entrambe le stringhe corrisponde, il server ha verificato che le richieste provengono dallo stesso client e rilascerà unaccess token
. -
OAuth2 restituisce
access token
, e facoltativamente unrefresh token
. -
L’applicazione può ora utilizzare questi token per chiamare il server delle risorse, ad esempio un’API per conto dell’utente.
-
Il server delle risorse convalida il token prima di rispondere alla richiesta.
Configurare l’applicazione
Prima di implementare l’autorizzazione, è necessario registrare l’app in OAuth2 creando un’integrazione di app da Workfront.
Per istruzioni sulla creazione dell'applicazione OAuth2, vedi Creare un’applicazione web OAuth2 a pagina singola utilizzando PKCE in Creazione di applicazioni OAuth2 per le integrazioni Workfront
Creare la bozza della chiave per lo scambio di codice
Simile al flusso del codice di autorizzazione standard, l’app inizia reindirizzando il browser dell’utente a quello del server di autorizzazione. /authorize
endpoint. Tuttavia, in questo caso è anche necessario trasmettere una richiesta di codice.
Il primo passaggio consiste nel generare un codice di validazione e una richiesta di verifica.
Devi aggiungere il codice nell’app client per creare il codice di validazione e il codice di autenticazione.
Il codice del generatore PKCE crea un output simile al seguente:
code language-none |
---|
|
L'app salva code_verifier
per dopo, e invia code_challenge
insieme alla richiesta di autorizzazione al server di autorizzazione /authorize
URL.
Richiedi un codice di autorizzazione
Se utilizzi il server di autorizzazione personalizzato predefinito, l’URL della richiesta sarà simile al seguente:
code language-none |
---|
|
Prendi nota dei parametri che vengono passati:
-
client_id
corrisponde all'ID client dell'applicazione OAuth2 creata in durante la configurazione dell'applicazione.Per istruzioni, consulta Creare un’applicazione web a pagina singola OAuth2 utilizzando PKCE in Creare applicazioni OAuth2 per le integrazioni Workfront.
-
response_type
ècode
, perché l'applicazione utilizza il tipo di concessione Codice di autorizzazione. -
redirect_uri
è la posizione di callback a cui viene indirizzato l’agente utente insieme alcode
. Deve corrispondere a uno degli URL di reindirizzamento specificati al momento della creazione dell’applicazione OAuth2. -
code_challenge_method
è il metodo hash utilizzato per generare la sfida, che è sempreS256
per applicazioni Workfront Oauth2 che utilizzano PKCE. -
code_challenge
è la richiesta di verifica del codice utilizzata per PKCE.
Scambia il codice con i token
Per scambiare il codice di autorizzazione con un token di accesso, trasmettilo al server autorizzazioni /token
endpoint insieme al code_verifier
.
code language-none |
---|
|
Prendi nota dei parametri che vengono passati:
-
grant_type
èauthorization_code
, perché l’app utilizza il tipo di concessione Codice di autorizzazione. -
redirect_uri
deve corrispondere all’URI utilizzato per ottenere il codice di autorizzazione. -
code
è il codice di autorizzazione ricevuto dall'endpoint /authorize. -
code_verifier
è il codice di validazione PKCE generato dall’app in Creare la bozza della chiave per lo scambio di codice. -
client_id
identifica il client e deve corrispondere al valore preregistrato in OAuth2.
Se il codice è ancora valido e il codice di validazione corrisponde a, l’applicazione riceve un token di accesso.
code language-none |
---|
|
Convalidare il token di accesso
Quando l’applicazione trasmette una richiesta con un token di accesso, il server delle risorse deve convalidarla.
Puoi convalidare il token di accesso con una chiamata API simile alla seguente:
code language-none |
---|
|
Richiedi un token di aggiornamento
Per richiedere un token di aggiornamento, puoi effettuare una chiamata POST all’API, simile alla seguente:
code language-none |
---|
|