Nutzer mit Okta authentifizieren

Auf dieser Seite wird gezeigt, wie Sie die Nutzerauthentifizierung in Cloud Endpoints unterstützen.

Zur Authentifizierung eines Nutzers muss eine Clientanwendung ein JSON-Webtoken (JWT) im Autorisierungs-Header der HTTP-Anfrage an Ihre Back-End-API senden. Der Extensible Service Proxy (ESP) validiert das Token für Ihre API, sodass Sie der API keinen Code zur Verarbeitung der Authentifizierung hinzufügen müssen. Sie müssen Ihr OpenAPI-Dokument jedoch so konfigurieren, dass es die ausgewählten Authentifizierungsmethoden unterstützt.

Der ESP prüft ein JSON-Webtoken (JWT) effizient mithilfe der öffentlichen Schlüssel des JWT-Ausstellers. Dabei speichert der ESP die öffentlichen Schlüssel 5 Minuten lang im Cache. Darüber hinaus speichert der ESP validierte JWTs 5 Minuten lang oder bis zum Ablauf des JWT, je nachdem, was zuerst eintritt.

Hinweise

  • Wenn Ihre Clientanwendung eine HTTP-Anfrage sendet, muss der Autorisierungs-Header in der Anfrage die folgenden JWT-Anforderungen enthalten:
    • iss (issuer)
    • sub (subject)
    • aud (audience)
    • iat (issued at)
    • exp (expiration time)

ESP für die Clientauthentifizierung konfigurieren

Das OpenAPI-Dokument muss ein Objekt für Sicherheitsanforderungen und ein Objekt für Sicherheitsdefinitionen enthalten, damit der ESP die Anforderungen im signierten JWT validieren kann.

Wie im Okta-Integrationsleitfaden für Google Cloud Endpoints erläutert, nehmen Sie die folgenden Änderungen an Ihrem OpenAPI-Dokument vor:

  1. Fügen Sie der Sicherheitsdefinition in Ihrem OpenAPI-Dokument Folgendes hinzu: Ersetzen Sie YOUR_OKTA_TENANT_NAME durch den Namen Ihres Okta-Mandanten und YOUR_OKTA_CLIENT_ID durch die Client-ID, die Sie im Okta-Mandanten erstellt haben.

          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"
    
  2. Fügen Sie den Abschnitt "security" entweder für die gesamte API auf API-Ebene oder für eine bestimmte Methode auf Methodenebene hinzu.

      security:
        - okta_jwt: []
    

Sie können mehrere Sicherheitsdefinitionen im OpenAPI-Dokument angeben, allerdings muss jede Definition einen anderen Aussteller haben. Wenn Sie den Abschnitt security sowohl auf der API-Ebene als auch auf der Methodenebene verwenden, werden die Einstellungen auf der API-Ebene durch die Einstellungen auf der Methodenebene überschrieben.

Das Feld x-google-audiences ist nicht erforderlich. ESP akzeptiert alle JWTs mit dem Back-End-Dienstnamen im Format https://SERVICE_NAME im Anspruch aud. Damit zusätzliche Client-IDs auf den Back-End-Dienst zugreifen können, können Sie die zulässigen Client-IDs im Feld x-google-audiences durch kommagetrennte Werte angeben. Der ESP akzeptiert dann die JWTs mit einer der angegebenen Client-IDs im Anspruch aud.

Authentifizierter Aufruf an eine Endpoints API

Wenn Sie eine Anfrage mit einem Authentifizierungstoken senden, empfehlen wir aus Sicherheitsgründen, das Token in den Header Authorization:Bearer einzufügen. Beispiel:

curl -H "Authorization: Bearer ${TOKEN}" "${ENDPOINTS_HOST}/echo"

Hier sind ENDPOINTS_HOST und TOKEN Umgebungsvariablen, die den Hostnamen Ihrer API beziehungsweise das Authentifizierungstoken enthalten. Weitere Informationen für einen Beispielcode zum Senden einer Anfrage mit dem Authorization:Bearer-Header finden Sie unter Authentifizierte Anfrage an eine Endpoints API senden.

Falls Sie den Header nicht verwenden können, wenn Sie die Anfrage senden, können Sie das Authentifizierungstoken in einen Abfrageparameter namens access_token einfügen.

curl "${ENDPOINTS_HOST}/echo?access_token=${TOKEN}"

Authentifizierte Ergebnisse in Ihrer API empfangen

Der ESP leitet in der Regel alle empfangenen Header weiter. Der ESP überschreibt aber möglicherweise den ursprünglichen Authorization-Header, wenn die Back-End-Adresse in der OpenAPI-Spezifikation durch x-google-backend oder in der gRPC-Dienstkonfiguration mit BackendRule angegeben wird.

ESP sendet das Authentifizierungsergebnis in X-Endpoint-API-UserInfo an die Back-End-API. Es wird empfohlen, diesen Header anstelle des ursprünglichen Authorization-Headers zu verwenden. Dieser Header ist base64url-codiert und enthält das folgende JSON-Objekt:

{
  "id": "from-sub",
  "issuer": "from-iss",
  "email": "from-email",
  "audiences": ["from-aud"],
  "claims": {
     original-jwt-payload
   }
}

Wenn Sie ESPv2 Beta verwenden, hat der Wert im Header ein unterschiedliches Format. Weitere Informationen zum neuen Format finden Sie unter Zu Extensible Service Proxy V2 Beta migrieren.

Nächste Schritte