Einführung in OAuth

Snowflake unterstützt das OAuth 2.0-Protokoll für Authentifizierung und Autorisierung. OAuth ist ein Open-Standard-Protokoll, das unterstützten Clients autorisierten Zugriff auf Snowflake gewährt, ohne dass Anmeldeinformationen des Benutzers freigegeben oder gespeichert werden müssen. Dies wird als delegierte Autorisierung bezeichnet, da ein Benutzer den Client autorisiert, in seinem Namen zu handeln und seine Daten abzurufen. Snowflake bietet zwei OAuth-Pfade: Snowflake OAuth und External OAuth.

Snowflake OAuth verwendet den integrierten OAuth-Dienst von Snowflake und unterstützt die folgenden Anwendungen:

External OAuth integriert den OAuth 2.0-Server eines Kunden und unterstützt drei Autorisierungsserveroptionen, benutzerdefinierte Clients und zwei Partneranwendung.

In der folgenden Tabelle werden Snowflake OAuth und External OAuth verglichen.

Kategorie

Snowflake OAuth

External OAuth

Clientanwendung ändern

Erforderlich

Erforderlich

Zugriff auf Browser der Clientanwendung

Erforderlich

Nicht erforderlich

Programmgesteuerte Clients

Benötigt einen Browser

Optimale Größe

Treibereigenschaft

authenticator = oauth

authenticator = oauth

Sicherheitsintegrationssyntax

create security integration type = oauth ...

create security integration type = external_oauth

OAuth-Ablauf

OAuth 2.0-Codegenehmigungsablauf

Jeder OAuth-Ablauf, den der Client mit dem External OAuth-Server initiieren kann

Snowflake erlaubt OAuth für Clients durch Integrationen. Eine Integration ist ein Snowflake-Objekt, das eine Schnittstelle zwischen Snowflake und Services von Drittanbietern bereitstellt. Administratoren konfigurieren OAuth mithilfe einer Sicherheitsintegration, einem Integrationstyp, mit dem Clients, die OAuth unterstützen, Benutzer auf eine Autorisierungsseite weiterleiten und Zugriffstoken (sowie optional Aktualisierungstoken) für den Zugriff auf Snowflake generieren können.

Unter diesem Thema:

OAuth-Konzepte

Autorisierungsserver

Dieser Server zeigt einem Benutzer eine Schnittstelle an, über die er den Clientzugriff auf seine Daten zulassen oder verweigern kann. Der Server stellt ein Zugriffstoken an den Client aus, nachdem der Benutzer authentifiziert und eine Autorisierungsanforderung erfolgreich validiert wurde.

Zugriffstoken

Eine Zeichenfolge, die die Autorisierung darstellt, die einem Client von einem Benutzer für den Zugriff auf seine Daten mittels einer angegebenen Rolle erteilt wird. Diese Token verfallen nach kurzer Zeit. Über einen Aktualisierungsmechanismus können jedoch neue Zugriffstoken abgerufen werden.

Aktualisierungstoken

Eine Zeichenfolge, die bei Ablauf eines Tokens zum Abrufen eines neuen Zugriffstokens dient. Zusammen mit einem Zugriffstoken wird vom Autorisierungsserver optional ein Aktualisierungstoken an den Client ausgegeben. Der Client kann das Aktualisierungstoken verwenden, um ein anderes Zugriffstoken anzufordern, ohne den Benutzer erneut beteiligen zu müssen, bis das Aktualisierungstoken abläuft. An diesem Punkt wird der OAuth-Workflow erneut aufgerufen.

Ressourcenserver

Dieser Server schützt die Ressourcen (d. h. Snowflake) und verarbeitet Anforderungen nach Zugriff auf die Ressource mithilfe von Zugriffstoken.

Vertrauliche und öffentliche Clients

Vertrauliche Clients können das OAuth-Clientgeheimnis speichern. Sie werden in einem geschützten Bereich ausgeführt, auf den Endbenutzer nicht zugreifen können. Ein in der Cloud bereitgestellter, sicherer Service kann beispielsweise ein vertraulicher Client sein. Ein Client, der hingegen auf einem Desktop ausgeführt oder über einen App Store verteilt wird, kann ein öffentlicher Client sein.

Bei öffentlichen Clients muss der Benutzer den Clientzugriff auf Snowflake jedes Mal mit einer bestimmten Rolle autorisieren. Bei vertraulichen Clients muss der Benutzer den Clientzugriff für eine bestimmte Rolle nur einmal eingeben.

Snowflake unterstützt OAuth für vertrauliche und öffentliche Clients.

Snowflake OAuth-Autorisierungsablauf

Der OAuth-Autorisierungsablauf sieht wie folgt aus:

Snowflake OAuth workflow
  1. Im Client versucht der Benutzer, mit OAuth eine Verbindung zu Snowflake herzustellen.

    Die Anwendung sendet eine Autorisierungsanforderung an den Snowflake-Autorisierungsserver. Daraufhin wird ein Autorisierungsbildschirm angezeigt, in dem der Benutzer aufgefordert wird, den Zugriff zu autorisieren.

  2. Der Benutzer gibt seinen Snowflake-Anmeldenamen und sein Kennwort ein. Daraufhin wird ihm ein Zustimmungsdialogfeld angezeigt, in dem er Snowflake den Clientzugriff unter Verwendung einer bestimmten Rolle in einer Benutzersitzung (z. B. SYSADMIN oder CUSTOM_ROLE1) erlaubt.

    Der Benutzer übermittelt seine Zustimmung, die spezifische Rolle in einer Sitzung zu verwenden.

    Der Snowflake-Autorisierungsserver sendet einen Autorisierungscode an den Client zurück.

  3. Der Client sendet den Autorisierungscode zurück an den Snowflake-Autorisierungsserver, um ein Zugriffstoken und optional ein Aktualisierungstoken anzufordern, damit der Client neue Zugriffstoken abrufen kann.

    Der Snowflake-Autorisierungsserver akzeptiert den Autorisierungscode und stellt dem Client ein Zugriffstoken zur Verfügung, das für die Benutzerressourcen im Snowflake-Ressourcenserver spezifisch ist. Je nach den Einstellungen in der Autorisierungsanforderung stellt der Autorisierungsserver ein Aktualisierungstoken aus, damit sich neue Zugriffstoken abrufen lassen, die an die bestimmte Ressource gebunden sind.

  4. Der Client sendet das Zugriffstoken an den Snowflake-Ressourcenserver.

    Der Ressourcenserver erkennt das gültige Zugriffstoken und richtet eine Benutzersitzung mit der autorisierten Rolle ein. Der Client hat jetzt Zugriff auf die Snowflake-Ressourcen, beschränkt durch die im Zugriffstoken angegebene Rolle.

Zugriffstoken haben eine kurze Lebensdauer (normalerweise 10 Minuten). Wenn das Zugriffstoken abläuft, kann der Client ein Aktualisierungstoken senden, um neue Zugriffstoken anzufordern. Ein Aktualisierungstoken wird an den Snowflake-Autorisierungsserver gesendet, um jedes Mal, wenn das aktuelle Zugriffstoken abläuft, ein neues Zugriffstoken anzufordern (Schritte 3-6). Wenn die Integration so konfiguriert ist, dass das Senden von Aktualisierungstoken verhindert wird, muss der Benutzer die oben genannten Schritte wiederholen, um den Client neu zu autorisieren.

Konfigurieren von OAuth-Unterstützung

Snowflake OAuth-Partneranwendungen

Informationen zum Konfigurieren der Unterstützung finden Sie unter Snowflake OAuth für Partneranwendungen konfigurieren.

Weitere Informationen zur Verwendung von OAuth unter Umgehung des öffentlichen Internets finden Sie unter OAuth und private Konnektivität.

Benutzerdefinierte Snowflake OAuth-Clients

Snowflake unterstützt benutzerdefinierte Clients, die von Ihrer Organisation konfiguriert wurden. Informationen zum Konfigurieren der Unterstützung finden Sie unter Snowflake OAuth für benutzerdefinierte Clients konfigurieren.

External OAuth-Partneranwendungen

Informationen zur Konfiguration von External OAuth-Partneranwendungen finden Sie unter External OAuth-Partneranwendungen.

Benutzerdefinierte External OAuth-Clients

Snowflake unterstützt benutzerdefinierte External OAuth-Clients, die von Ihrem Unternehmen konfiguriert wurden. Informationen zum Konfigurieren der Unterstützung finden Sie unter Benutzerdefinierte Clients für External OAuth konfigurieren.

Überwachen von OAuth-Anmeldungen

Damit sich Anmeldeversuche von Snowflake-Benutzern abfragen lassen, stellt Snowflake einen Anmeldeverlauf zur Verfügung:

Wenn OAuth zur Authentifizierung verwendet wird (ob erfolgreich oder nicht), hat die Spalte FIRST_AUTHENTICATION_FACTOR in der Ausgabe den Wert OAUTH_ACCESS_TOKEN.

Integrations-DDL

Zur Unterstützung beim Erstellen und/oder Verwalten von Integrationen und delegierten Autorisierungen bietet Snowflake folgende spezielle DDL-Befehle:

OAuth und Verbundauthentifizierung

Snowflake unterstützt OAuth mit Verbundauthentifizierung und SSO (Single Sign-On) unter Verwendung beliebiger von Snowflake unterstützter Identitätsanbieter (IdP).

Wenn Verbundauthentifizierung konfiguriert ist, sieht der Autorisierungsablauf wie folgt aus:

  1. Im Client versucht der Benutzer, eine Verbindung zu Snowflake herzustellen.

    Die Anwendung sendet eine Autorisierungsanforderung an den Snowflake-Autorisierungsserver. Daraufhin wird ein Autorisierungsbildschirm angezeigt, in dem der Benutzer aufgefordert wird, den Zugriff zu autorisieren.

  2. Der Benutzer klickt auf die Option zum Anmelden via IdP und wird zur IdP-Authentifizierungsseite weitergeleitet.

  3. Der Benutzer gibt seinen IdP-Anmeldenamen und sein Kennwort ein. Daraufhin wird ihm ein Zustimmungsdialogfeld angezeigt, in dem er Snowflake den Clientzugriff unter Verwendung einer bestimmten Rolle in einer Benutzersitzung (z. B. SYSADMIN oder CUSTOM_ROLE1) erlaubt.

    Der Benutzer übermittelt seine Zustimmung, die spezifische Rolle in einer Sitzung zu verwenden.

    Der Snowflake-Autorisierungsserver sendet einen Autorisierungscode an den Client zurück.

  4. Der Client sendet den Autorisierungscode zurück an den Snowflake-Autorisierungsserver, um ein Zugriffstoken und optional ein Aktualisierungstoken anzufordern, damit der Client neue Zugriffstoken abrufen kann.

    Der Snowflake-Autorisierungsserver akzeptiert den Autorisierungscode und stellt dem Client ein Zugriffstoken zur Verfügung, das für die Benutzerressourcen im Snowflake-Ressourcenserver spezifisch ist. Je nach den Einstellungen in der Autorisierungsanforderung stellt der Autorisierungsserver ein Aktualisierungstoken aus, damit sich neue Zugriffstoken abrufen lassen, die an die bestimmte Ressource gebunden sind.

  5. Der Client sendet das Zugriffstoken an den Snowflake-Ressourcenserver.

    Der Ressourcenserver erkennt das gültige Zugriffstoken und richtet eine Benutzersitzung mit der autorisierten Rolle ein. Der Client hat jetzt Zugriff auf die Snowflake-Ressourcen, beschränkt durch die im Zugriffstoken angegebene Rolle.

OAuth und private Konnektivität

Snowflake unterstützt die Verwendung von External OAuth mit Private Konnektivität zum Snowflake-Dienst.

Snowflake OAuth und Tableau können wie folgt mit privater Konnektivität zu Snowflake verwendet werden:

Tableau Desktop

Ab Version 2020.4 enthält Tableau einen eingebetteten OAuth-Client, der die Verbindung zu Snowflake mit der Konto-URL für Private Konnektivität zum Snowflake-Dienst unterstützt.

Nach dem Upgrade auf Tableau 2020.4 ist keine weitere Konfiguration erforderlich. Verwenden Sie die entsprechende private Konnektivitäts-URL für AWS oder Azure, um sich mit Snowflake zu verbinden.

Tableau Server

Ab Tableau 2020.4 können Benutzer Tableau Server optional so konfigurieren, dass der eingebettete OAuth-Client verwendet wird, um eine Verbindung zu Snowflake über die Konto-URL für Private Konnektivität zum Snowflake-Dienst herzustellen.

Zur Verwendung dieser Funktion müssen Sie eine neue Custom Client-Sicherheitsintegration erstellen und die Tableau-Anweisungen befolgen.

Tableau Online

Tableau Online bietet keine Unterstützung der Snowflake-Konto-URL für Private Konnektivität zum Snowflake-Dienst, da Tableau Online Zugriff auf das öffentliche Internet benötigt.

Wenden Sie sich an Tableau, um weitere Informationen darüber zu erhalten, wann Tableau Online private Konnektivität über Snowflake-Konto-URLs für Private Konnektivität zum Snowflake-Dienst unterstützen wird.

Wichtig

Um die Konto-URL zu bestimmen, die für Private Konnektivität zum Snowflake-Dienst verwendet werden soll, rufen Sie die Funktion SYSTEM$GET_PRIVATELINK_CONFIG auf.

Looker

Derzeit erfordert die Kombination von Snowflake OAuth und Looker einen Zugang zum öffentlichen Internet. Daher können Sie Snowflake OAuth und Looker nicht mit Private Konnektivität zum Snowflake-Dienst verwenden.

Weitere Informationen dazu finden Sie unter:

OAuth und Netzwerkrichtlinien

Sie können eine dedizierte Netzwerkrichtlinie nur mit Snowflake OAuth integrieren. Die External OAuth-Sicherheitsintegration unterstützt nicht die Festlegung einer separaten Netzwerkrichtlinie, aber Sie können dennoch eine allgemeine Netzwerkrichtlinie verwenden, die für das gesamte Snowflake-Konto gilt.

Die Snowflake OAuth-Sicherheitsintegration verfügt über einen network_policy-Parameter, sodass die Snowflake OAuth-Integration Benutzer authentifizieren und autorisieren kann, ohne diese IP-Adressen für den normalen Benutzerzugriff hinzuzufügen.

Durch das Einrichten einer für die Snowflake OAuth-Integration spezifischen Netzwerkrichtlinie kann sich die Snowflake OAuth-Netzwerkrichtlinie von anderen Netzwerkrichtlinien unterscheiden, die möglicherweise für das Snowflake-Konto gelten. Die Snowflake OAuth-Netzwerkrichtlinie wirkt sich nicht auf andere Netzwerkrichtlinien des Kontos aus, und ebenso wirken sich andere Netzwerkrichtlinien des Kontos nicht auf die Snowflake OAuth-Netzwerkrichtlinie aus. Daher ermöglicht die Snowflake OAuth-Netzwerkrichtlinie die Authentifizierung und Autorisierung von Benutzern wie beabsichtigt.

Wichtig

Wenn eine Netzwerkrichtlinie pro Benutzer oder Konto festgelegt ist und Sie einen Dienst verwenden, der an einem anderen Speicherort ausgeführt wird (z. B. Microsoft Power BI), können Sie keine Verbindung zu Snowflake herstellen.

Legen Sie nach dem Erstellen der Snowflake OAuth-Sicherheitsintegration die OAuth-Netzwerkrichtlinie mit dem folgenden Befehl fest:

alter security integration <OAuth-Integration> set network_policy = <OAuth-Netzwerkrichtlinie>;

Verwenden Sie folgenden Befehl, um die OAuth-Netzwerkrichtlinie zu deaktivieren:

alter security integration <OAuth-Integration> unset <OAuth-Netzwerkrichtlinie>;

Wobei:

<oauth_integration>

Gibt den Namen der OAuth-Sicherheitsintegration an.

<oauth_network_policy>

Gibt die Snowflake OAuth-Netzwerkrichtlinie in Snowflake an.

Weitere Informationen dazu finden Sie unter Netzwerkrichtlinien und ALTER SECURITY INTEGRATION (Snowflake OAuth).

OAuth und Sekundärrollen

Snowflake unterstützt die Verwendung von Sekundärrollen mit External OAuth.

Weitere Informationen dazu finden Sie unter Verwenden von Sekundärrollen mit External OAuth.

Beachten Sie, dass ein sitzungsinterner Rollenwechsel zu Sekundärrollen mit Snowflake OAuth nicht unterstützt wird.

OAuth mit Clients, Treibern und Konnektoren

Unterstützte Clients, Treiber und Konnektoren können OAuth verwenden, um die Anmeldeinformationen des Benutzers zu überprüfen.

Beachten Sie Folgendes:

  • Es ist notwendig, den Parameter authenticator auf oauth und den Parameter token auf oauth_access_token zu setzen.

  • Wenn Sie den token-Wert als URL-Abfrageparameter übergeben, muss der oauth_access_token-Wert als URL codiert werden.

  • Wenn Sie den token-Wert an ein Properties-Objekt übergeben (z. B. JDBC-Treiber), sind keine Anpassungen erforderlich.

Weitere Informationen dazu finden Sie in den Verbindungsparametern für jeden Client, Treiber oder Konnektor.

OAuth und Clientumleitung

Snowflake unterstützt die Verwendung der Clientumleitung mit Snowflake-OAuth und External OAuth, einschließlich der Verwendung der Clientumleitung und OAuth bei unterstützten Snowflake-Clients.

Weitere Informationen dazu finden Sie unter Umleiten von Clientverbindungen.

OAuth und Replikation

Snowflake unterstützt Replikation und Failover/Failback von Snowflake OAuth- und External OAuth-Sicherheitsintegrationen vom Quellkonto in das Zielkonto.

Weitere Details dazu finden Sie unter Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg.

OAuth-Fehlercodes

Die folgenden Fehlercodes stehen mit OAuth in Verbindung und können während des Authentifizierungsablaufs, des Tokenaustauschs oder beim Erstellen einer Snowflake-Sitzung nach Abschluss des OAuth-Ablaufs zurückgegeben werden:

Fehlercode

Fehler

Beschreibung

390302

OAUTH_CONSENT_INVALID

Problem mit dem Generieren oder Validieren von Zustimmung für einen bestimmten Benutzer

390303

OAUTH_ACCESS_TOKEN_INVALID

Das Zugriffstoken, das beim Versuch, eine Snowflake-Sitzung herzustellen, angegeben wurde, ist abgelaufen oder ungültig.

390304

OAUTH_AUTHORIZE_INVALID_RESPONSE_TYPE

Es wurde ein ungültiger Antworttyp response_type als Parameter für den Autorisierungsendpunkt angegeben (er sollte höchstwahrscheinlich code lauten).

390305

OAUTH_AUTHORIZE_INVALID_STATE_LENGTH

Der Statusparameter, der als Parameter für den Autorisierungsendpunkt angegeben ist, überschreitet 2.048 Zeichen

390306

OAUTH_AUTHORIZE_INVALID_CLIENT_ID

Die mit einer angegebenen Client-ID verknüpfte Integration ist nicht vorhanden.

390307

OAUTH_AUTHORIZE_INVALID_REDIRECT_URI

Die redirect_uri, die als Parameter für den Autorisierungsendpunkt angegeben ist, stimmt nicht mit der redirect_uri der Integration überein, die mit der angegebenen client_id verknüpft ist, oder die redirect_uri ist nicht korrekt formatiert.

390308

OAUTH_AUTHORIZE_INVALID_SCOPE

Entweder ist der angeforderte Bereich kein gültiger Bereich, oder dem Benutzer kann kein vollständiger Zugriff auf die angeforderten Bereiche gewährt werden.

390309

OAUTH_USERNAMES_MISMATCH

Der Benutzer, als den Sie sich zu authentifizieren versuchten, unterscheidet sich von dem Benutzer, der an das Zugriffstoken gebunden ist.

390311

OAUTH_AUTHORIZE_INVALID_CODE_CHALLENGE_PARAMS

Entweder die Code-Challenge oder die Code-Challenge-Methode fehlt, ist ungültig oder wird nicht unterstützt.

390318

OAUTH_ACCESS_TOKEN_EXPIRED

OAuth-Zugriffstoken ist abgelaufen. {0}

390144

JWT_TOKEN_INVALID

JWT-Token ist ungültig.

Darüber hinaus werden die folgenden Fehler aus dem RFC übernommen und im JSON-Blob zurückgegeben, das während einer nicht erfolgreichen Tokenanforderung oder eines fehlgeschlagenen Tokenaustauschs erstellt wurde:

Fehler

Beschreibung

invalid_client

In Bezug auf die Clientauthentifizierung ist ein Fehler aufgetreten, z. B. war der Client unbekannt, lag ein Konflikt des Clientgeheimnisses vor usw.

invalid_grant

Die angegebene Autorisierungsgewährung oder das Aktualisierungstoken sind ungültig, abgelaufen, widerrufen, stimmen nicht mit dem in der Autorisierungsanforderung verwendeten Weiterleitungs-URI überein oder wurden an einen anderen Client ausgestellt.

unsupported_grant_type

Es wurde ein Gewährungstyp bereitgestellt, den Snowflake derzeit nicht unterstützt („refresh_token“ und „authorized_code“ sind derzeit die einzigen unterstützten Gewährungstypen).

invalid_request

Die Anforderung war falsch formatiert oder konnte nicht verarbeitet werden.

Zurück zum Anfang