Utilizzo di Okta per autenticare gli utenti

Questa pagina descrive come supportare l'autenticazione utente in Cloud Endpoints.

Per autenticare un utente, un'applicazione client deve inviare un token web JSON (JWT) nell'intestazione di autorizzazione della richiesta HTTP alla tua API di backend. Extensible Service Proxy (ESP) convalida il token per conto della tua API, quindi non devi aggiungere codice alla tua API per elaborare l'autenticazione. Tuttavia, devi configurare il documento OpenAPI per supportare i metodi di autenticazione scelti.

ESP convalida un JWT in modo efficiente utilizzando le chiavi pubbliche dell'emittente del JWT. ESP memorizza nella cache le chiavi pubbliche per cinque minuti. Inoltre, ESP memorizza nella cache i JWT convalidati per cinque minuti o fino alla scadenza del JWT, a seconda di quale si verifica per primo.

Prima di iniziare

  • Quando l'applicazione client invia una richiesta HTTP, l'intestazione di autorizzazione nella richiesta deve contenere le seguenti rivendicazioni JWT:
    • iss (emittente)
    • sub (oggetto)
    • aud (pubblico)
    • iat (emesso il giorno)
    • exp (data/ora di scadenza)

Configurazione di ESP per supportare l'autenticazione client

Devi avere un oggetto requisito di sicurezza e un oggetto definizioni di sicurezza nel documento OpenAPI affinché ESP convalida le rivendicazioni nel JWT firmato.

Come spiegato nella guida all'integrazione di Okta per Google Cloud Endpoints, apporti le seguenti modifiche al documento OpenAPI:

OpenAPI 2.0

  1. Aggiungi quanto segue alla specifica OpenAPI:
    securityDefinitions:
      okta_jwt:
        authorizationUrl: ""
        flow: "implicit"
        type: "oauth2"
        x-google-issuer: "https://YOUR_OKTA_TENANT_NAME.com"
        x-google-jwks_uri: "https://YOUR_OKTA_TENANT_NAME.com/oauth2/v1/keys"
        x-google-audiences: "YOUR_OKTA_CLIENT_ID"

    Dove:

    • YOUR_OKTA_TENANT_NAME è il nome del tuo tenant Okta.
    • YOUR_OKTA_CLIENT_ID è l'ID client che hai creato nel tuo tenant Okta.
  2. Aggiungi una sezione di sicurezza a livello di API da applicare all'intera API o a livello di metodo da applicare a un metodo specifico.
    security:
       -   okta_jwt: []

OpenAPI 3.x

  1. Aggiungi quanto segue alla specifica OpenAPI:
    components:
      securitySchemes:
        okta_jwt:
          type: oauth2
          flows:
           implicit:
             authorizationUrl: ""
             scopes: {}
          x-google-auth:
            issuer: https://YOUR_OKTA_TENANT_NAME.com
            jwksUri: https://YOUR_OKTA_TENANT_NAME.com/oauth2/v1/keys
            # Optional.
            audiences:
              - YOUR_OKTA_CLIENT_ID

    Dove:

    • YOUR_OKTA_TENANT_NAME è il nome del tuo tenant Okta.
    • YOUR_OKTA_CLIENT_ID è l'ID client che hai creato nel tuo tenant Okta.
  2. Aggiungi una sezione di sicurezza a livello di API da applicare all'intera API o a livello di metodo da applicare a un metodo specifico.
    security:
      - okta_jwt: []

Puoi definire più definizioni di sicurezza nel documento OpenAPI, ma ogni definizione deve avere un emittente diverso. Se utilizzi sezioni di sicurezza sia a livello di API sia a livello di metodo, le impostazioni a livello di metodo sostituiscono quelle a livello di API.

Il campo x-google-audiences o audiences non è obbligatorio. ESP accetta tutti i JWT con il nome del servizio di backend nel formato https://SERVICE_NAME nella rivendicazione aud. Per consentire a ID client aggiuntivi di accedere al servizio di backend, puoi specificare gli ID client consentiti nel campo x-google-audiences o audiences utilizzando valori separati da virgole. ESP accetta quindi i JWT con uno qualsiasi degli ID client specificati nell'attestazione aud.

Puoi anche personalizzare le posizioni JWT aggiungendo estensioni x-google. Per maggiori dettagli, vedi Estensioni OpenAPI 2.0 o Estensioni OpenAPI 3.x.

Eseguire una chiamata autenticata a un'API Endpoints

Quando invii una richiesta utilizzando un token di autenticazione, per motivi di sicurezza ti consigliamo di inserire il token nell'intestazione Authorization:Bearer. Ad esempio:

curl -H "Authorization: Bearer <var>TOKEN</var>" "<var>ENDPOINTS_HOST</var>/echo"

Qui, sostituisci le variabili ENDPOINTS_HOST e TOKEN con il nome host API e il token di autenticazione, rispettivamente. Consulta Eseguire una richiesta autenticata a un'API Endpoints per un codice campione che invia una richiesta utilizzando l'intestazione Authorization:Bearer.

Se non puoi utilizzare l'intestazione quando invii la richiesta, puoi inserire il token di autenticazione in un parametro di query denominato access_token. Ad esempio:

curl "<var>ENDPOINTS_HOST</var>/echo?access_token=<var>TOKEN</var>"

Ricevere risultati autenticati nell'API

In genere, l'ESP inoltra tutte le intestazioni che riceve. Tuttavia, esegue l'override dell'intestazione Authorization originale quando l'indirizzo di backend è specificato da x-google-backend nella specifica OpenAPI o da BackendRule nella configurazione del servizio gRPC.

ESP invierà il risultato dell'autenticazione in X-Endpoint-API-UserInfo all'API di backend. Ti consigliamo di utilizzare questa intestazione anziché l'intestazione Authorization originale. Questa intestazione è una stringa che base64url codifica un oggetto JSON. Il formato dell'oggetto JSON varia tra ESPv2 ed ESP. Per ESPv2, l'oggetto JSON è esattamente il payload JWT originale. Per ESP, l'oggetto JSON utilizza nomi di campi diversi e inserisce il payload JWT originale nel campo claims. Per saperne di più sul formato, consulta Gestire i JWT nel servizio di backend.

Passaggi successivi