Configuração do Snowflake OAuth para clientes personalizados

Este tópico descreve como configurar o suporte do OAuth para clientes personalizados.

Neste tópico:

Fluxo de trabalho

As seguintes etapas de alto nível são necessárias para configurar o OAuth para clientes personalizados:

  1. Registre seu cliente no Snowflake. Para registrar seu cliente, crie uma integração. Uma integração é um objeto Snowflake que fornece uma interface entre o Snowflake e serviços de terceiros, tais como um cliente que suporta OAuth.

    O processo de registro define uma ID de cliente e os segredos do cliente.

  2. Configure chamadas para os pontos de extremidade Snowflake OAuth para solicitar códigos de autorização do servidor de autorização do Snowflake e para solicitar e atualizar tokens de acesso.

    Os parâmetros opcionais de “escopo” no solicitação de autorização inicial limitam a função permitida pelo token de acesso e podem, adicionalmente, ser usados para configurar o comportamento de atualização de token.

Nota

A troca de funções durante a sessão para funções secundárias não tem suporte com o Snowflake OAuth.

Se este comportamento for necessário com seu fluxo de trabalho OAuth, use External OAuth.

Para obter mais informações, consulte Uso de funções secundárias com External OAuth.

Criação de uma integração do Snowflake OAuth

Crie uma integração do Snowflake OAuth usando o comando CREATESECURITYINTEGRATION. Certifique-se de especificar OAUTH_CLIENT = CUSTOM ao criar a integração.

Nota

Somente administradores de conta (usuários com a função ACCOUNTADMIN) ou uma função com o privilégio global CREATE INTEGRATION podem executar este comando SQL.

Bloqueio de funções específicas para o uso de integração

O parâmetro opcional BLOCKED_ROLES_LIST permite listar as funções do Snowflake que um usuário não pode consentir explicitamente em usar com a integração.

Por padrão, as funções ACCOUNTADMIN, SECURITYADMIN e ORGADMIN estão incluídas nesta lista e não podem ser removidas. Se você tiver uma necessidade comercial de permitir que os usuários usem o Snowflake OAuth com essas funções e se sua equipe de segurança permitir isso, entre em contato com o suporte Snowflake para solicitar que essas funções sejam permitidas para sua conta.

Uso do redirecionamento do cliente com clientes personalizados do Snowflake OAuth

O Snowflake oferece suporte para o uso do redirecionamento do cliente com clientes personalizados do Snowflake OAuth, incluindo o uso do redirecionamento do cliente e do OAuth com clientes Snowflake com suporte.

Para obter mais informações, consulte Redirecionamento de conexões do cliente.

Gerenciamento de políticas de rede

O Snowflake suporta políticas de rede para OAuth. Para obter mais informações, consulte Políticas de redes.

Exemplo de integração

O exemplo a seguir cria uma integração OAuth que utiliza autenticação de par de chaves. A integração permite tokens de atualização, que expiram após 1 dia (86400 segundos). A integração bloqueia o início de uma sessão com SYSADMIN como a função ativa:

CREATE SECURITY INTEGRATION oauth_kp_int
  TYPE = OAUTH
  ENABLED = TRUE
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = 'https://localhost.com'
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE
  OAUTH_REFRESH_TOKEN_VALIDITY = 86400
  BLOCKED_ROLES_LIST = ('SYSADMIN')
  OAUTH_CLIENT_RSA_PUBLIC_KEY ='
  MIIBI
  ...
  ';
Copy

Chamada dos pontos de extremidade do OAuth

Pontos de extremidade do OAuth são as URLs que os clientes chamam para solicitar códigos de autorização e para solicitar e atualizar tokens de acesso. Estes pontos de extremidade referem-se a políticas específicas do OAuth 2.0 executadas quando o ponto de extremidade é chamado.

O Snowflake oferece os seguintes pontos de extremidade OAuth:

Autorização:

<snowflake_account_url>/oauth/authorize

Solicitações de token:

<snowflake_account_url>/oauth/token-request

Em que <snowflake_account_url> é uma URL válida da conta Snowflake. Por exemplo, você pode usar os pontos de extremidade https://myorg-account_xyz.snowflakecomputing.com/oauth/authorize e https://myorg-account_xyz.snowflakecomputing.com/oauth/token-request. Para obter uma lista de formatos compatíveis com a URL de conta Snowflake, consulte Conexão com uma URL.

Para ver uma lista de pontos de extremidade OAuth válidos para uma integração de segurança, execute DESCRIBE INTEGRATION e confira os valores nas propriedades OAUTH_ALLOWED_AUTHORIZATION_ENDPOINTS e OAUTH_ALLOWED_TOKEN_ENDPOINTS.

Ponto de extremidade de autorização

O ponto de extremidade de autorização é utilizado para obter uma concessão de autorização após um usuário autorizar com sucesso um cliente com Snowflake.

Importante

O ponto de extremidade de autorização precisa ser aberto em um navegador com o qual o usuário possa interagir. Não use cURL com este ponto de extremidade.

O ponto de extremidade de autorização é o seguinte:

<snowflake_account_url>/oauth/authorize
Copy

Onde:

snowflake_account_url

Especifica uma URL de conta Snowflake válida. Por exemplo, https://myorg-account_xyz.snowflakecomputing.com/oauth/authorize.

Método HTTP

GET

Parâmetros de consulta

Nota

Os seguintes parâmetros devem ser codificados para URL.

Parâmetro

Tipo de dados

Obrigatório?

Descrição

client_id

Cadeia de caracteres

Sim

ID do cliente (fornecida pelo Snowflake quando o cliente é registrado)

response_type

Cadeia de caracteres

Sim

Tipo de resposta criada. Atualmente suporta o valor code, porque o Snowflake só emite códigos de autorização.

redirect_uri

Cadeia de caracteres

Sim

URI para onde o usuário é redirecionado após a autorização com sucesso. Em geral, isso deve corresponder ao valor do parâmetro OAUTH_REDIRECT_URI da integração de segurança.

No entanto, se redirect_uri incluir parâmetros de consulta, não inclua esses parâmetros de consulta ao definir o parâmetro OAUTH_REDIRECT_URI da integração de segurança. Por exemplo, se o valor do parâmetro de consulta redirect_uri na solicitação para o ponto de extremidade de autorização for https://www.example.com/connect?authType=snowflake, certifique-se de que o parâmetro OAUTH_REDIRECT_URI na integração de segurança esteja definido como https://www.example.com/connect.

state

Cadeia de caracteres

Não

Cadeia de caracteres de não mais que 2048 caracteres ASCII que é retornado com a resposta do servidor de autorização do Snowflake. Tipicamente utilizado para impedir ataques de falsificação de solicitações entre sites.

scope

Cadeia de caracteres

Não

Cadeia de caracteres delimitada por espaços que é usada para limitar o escopo da solicitação de acesso. Para obter mais informações, consulte Escopo (neste tópico).

code_challenge

Cadeia de caracteres

Não

Challenge for Proof Key for Code Exchange (PKCE). Cadeia de caracteres gerada através de um segredo e de um método de desafio de código. Para obter mais informações, consulte Proof Key for Code Exchange (neste tópico).

code_challenge_method

Cadeia de caracteres

Não

Cadeia de caracteres indicando o método utilizado para derivar o desafio do código para PKCE. Para obter mais informações, consulte Proof Key for Code Exchange (neste tópico).

Quando um usuário autoriza o cliente, um redirecionamento é feito para o redirect_uri que contém o seguinte em uma solicitação GET:

Parâmetro de consulta

Descrição

code

Código de autorização de curta duração, que pode ser trocado no ponto de extremidade do token por um token de acesso.

state

Valor state fornecido na solicitação original, não modificado.

scope

Escopo da solicitação de acesso; atualmente o mesmo que o valor scope na solicitação de autorização inicial, mas pode ser diferente no futuro. Para obter mais informações, consulte Escopo (neste tópico).

Escopo

O parâmetro de consulta scope na solicitação de autorização inicial opcionalmente limita as operações e funções permitidas pelo token de acesso.

O escopo é validado imediatamente ao fazer uma solicitação de autorização com respeito à semântica, mas não necessariamente validade. Ou seja, qualquer escopo inválido (por exemplo, ”escopo_falso”) é rejeitado antes de o usuário se autenticar, mas um escopo ao qual o usuário não tem acesso (uma função específica, etc.) não resulta em erro até que o usuário se autentique.

A seguir estão os possíveis valores do parâmetro de consulta scope:

Valor do escopo

Obrigatório?

Descrição

refresh_token

Não

Se incluído na URL de autorização, o Snowflake apresenta ao usuário a opção de consentir ao acesso offline. Neste contexto, acesso offline refere-se a permitir que o cliente atualize os tokens de acesso quando o usuário não está presente. Com o consentimento do usuário, o servidor de autorização retorna um token de atualização, além de um token de acesso, ao resgatar o código de autorização.

session:role:role_name

Não

Usado para limitar o token de acesso a uma função única à qual o usuário pode consentir para a sessão. Apenas um único escopo de sessão pode ser especificado. Se este escopo for omitido, então a função padrão para o usuário é usada em seu lugar. Quando um usuário autoriza o consentimento, o Snowflake sempre exibe a função da sessão, independentemente se esse escopo está incluído na URL da autorização.

Observe que role_name faz distinção entre maiúsculas e minúsculas e deve ser inserido em letras maiúsculas, a menos que o nome da função tenha sido colocado entre aspas quando foi criado usando CREATE ROLE. Para verificar o caso, execute SHOW ROLES no Snowflake e consulte o nome da função na saída.

Se o nome da função contiver caracteres reservados em uma URL do parâmetro de consulta, você deve usar uma sintaxe session:role-encoded:role_name, onde role_name é uma cadeia de caracteres codificada de URL. Por exemplo, se o nome da função for AUTH SNOWFLAKE (com um espaço), então o valor do parâmetro de consulta scope deve ser session:role-encoded:AUTH%20SNOWFLAKE.

O exemplo a seguir limita a autorização à função personalizada R1:

scope=session:role:R1
Copy

O exemplo a seguir indica que os tokens de acesso/atualização devem usar a função padrão para o usuário e solicita um token de atualização para que o acesso offline possa ocorrer:

scope=refresh_token
Copy

O exemplo a seguir limita a autorização para a função personalizada R1 e solicita um token de atualização para que o acesso offline possa ocorrer:

scope=refresh_token session:role:R1
Copy

Ponto de extremidade de token

Este ponto de extremidade retorna tokens de acesso ou de atualização, dependendo dos parâmetros da solicitação. O ponto de extremidade de token é o seguinte:

<snowflake_account_url>/oauth/token-request
Copy

Onde:

snowflake_account_url

Especifica uma URL de conta Snowflake válida. Por exemplo, https://myorg-account_xyz.snowflakecomputing.com/oauth/token-request.

Método HTTP

POST

Certifique-se de que o cabeçalho do tipo de conteúdo na solicitação POST esteja definido como segue:

Content-type: application/x-www-form-urlencoded
Copy

Cabeçalho da solicitação

A ID e o segredo do cliente devem ser incluídos no cabeçalho da autorização. Atualmente, o Snowflake suporta apenas o Esquema de autenticação básico, o que significa que o valor esperado está na seguinte forma:

Basic Base64(client_id:client_secret)

Onde:

Valor do cabeçalho

Tipo de dados

Obrigatório

Descrição

client_id

Cadeia de caracteres

Sim

ID do cliente da integração.

client_secret

Cadeia de caracteres

Sim

Segredo do cliente para a integração.

Tanto a ID quanto o segredo do cliente podem ser recuperados usando a função SYSTEM$SHOW_OAUTH_CLIENT_SECRETS.

Observe o : caractere entre client_id e client_secret.

Corpo da solicitação

Parâmetro

Tipo de dados

Obrigatório

Descrição

grant_type

Cadeia de caracteres

Sim

Tipo de concessão solicitada: . authorization_code indica que um código de autorização deve ser trocado por um token de acesso. . refresh_token indica um solicitação de atualização de um token de acesso.

code

Cadeia de caracteres

Sim

Código de autorização retornado do ponto de extremidade de token. Usado e exigido quando grant_type está definido como authorization_code.

refresh_token

Cadeia de caracteres

Sim

O token de atualização retornado de um solicitação anterior para o ponto de extremidade de token ao resgatar o código de autorização. Usado e exigido quando grant_type está definido como refresh_token.

redirect_uri

Cadeia de caracteres

Sim

Redirecionar URI como usado no URL de autorização ao solicitar um código de autorização. Usado e exigido quando grant_type está definido como authorization_code.

code_verifier

Cadeia de caracteres

Não

Requerido somente se o solicitação de autorização foi enviada para o parâmetro do Ponto de extremidade de autorização com um valor de parâmetro code_challenge. Verificador de código para PKCE. Para obter mais informações, consulte Proof Key for Code Exchange (neste tópico).

Resposta

Um objeto JSON é retornado com os seguintes campos:

Campo

Tipo de dados

Descrição

access_token

Cadeia de caracteres

Token de acesso utilizada para estabelecer uma sessão do Snowflake

refresh_token

Cadeia de caracteres

Token de atualização. Não emitido se o cliente estiver configurado para não emitir tokens de atualização ou se o usuário não consentiu com o escopo de refresh_token.

expires_in

Inteiro

Número de segundos restantes até que o token expire

token_type

Cadeia de caracteres

Tipo de token de acesso. Atualmente, sempre Bearer.

username

Cadeia de caracteres

Nome de usuário ao qual o token de acesso pertence. Atualmente, só é retornado quando se troca um código de autorização por um token de acesso.

Exemplo de resposta bem-sucedida

O exemplo a seguir mostra uma resposta bem-sucedida ao trocar um código de autorização por um token de acesso e atualização:

{
  "access_token":  "ACCESS_TOKEN",
  "expires_in": 600,
  "refresh_token": "REFRESH_TOKEN",
  "token_type": "Bearer",
  "username": "user1",
}
Copy
Exemplo de resposta sem sucesso

O exemplo a seguir mostra uma resposta sem sucesso:

{
  "data" : null,
  "message" : "This is an invalid client.",
  "code" : null,
  "success" : false,
  "error" : "invalid_client"
}
Copy

O valor da cadeia de caracteres message é uma descrição do erro e error é o tipo de erro. Para obter mais informações sobre os tipos de erros retornados, consulte OAuth. Códigos de erro.

Proof Key for Code Exchange

O Snowflake suporta o Proof Key for Code Exchange (PKCE) para obter tokens de acesso usando o tipo de concessão authorization_code, conforme descrito em RFC 7636. O PKCE pode ser usado para diminuir a possibilidade de um ataque de interceptação de código de autorização e é adequado para clientes que podem não ser capazes de manter o segredo do cliente totalmente seguro.

Por padrão, o PKCE é opcional e só é aplicado se os parâmetros code_challenge e code_challenge_method estiverem ambos incluídos na URL do ponto de extremidade de autorização. Entretanto, o Snowflake recomenda fortemente que seu cliente exija PKCE para todas as autorizações para tornar o fluxo OAuth mais seguro.

O seguinte descreve como o PKCE para Snowflake funciona:

  1. O cliente cria um segredo chamado verificador de código e realiza uma transformação nele para gerar o desafio do código. O cliente guarda o segredo.

    Importante

    Gere o verificador de código a partir dos caracteres ASCII permitidos de acordo com a Seção 4.1 do RFC 7636.

  2. O cliente que direciona o usuário para a URL da autorização anexa os dois parâmetros de consulta seguintes:

    code_challenge

    Especifica o desafio de código gerado na Etapa 1.

    code_challenge_method

    Especifica as transformações usadas no verificador de código na Etapa 1 para gerar o desafio do código. Atualmente, o Snowflake suporta apenas SHA256, portanto, este valor deve ser definido como S256. O algoritmo de transformação para SHA256 é BASE64URL-ENCODE(SHA256(ASCII(code_verifier))).

  3. Depois que o usuário consente nos escopos solicitados ou o Snowflake determina que o consentimento está presente para esse usuário, o código de autorização é emitido.

  4. O cliente recebe o código de autorização do servidor de autorização do Snowflake, que ele então submete junto com o code_verifier na solicitação ao ponto de extremidade de token.

  5. Snowflake transforma o valor code_verifier e verifica se o valor transformado corresponde ao valor code_challenge usado na geração de autorizações. Se esses valores corresponderem, então o servidor de autorização emite os tokens de acesso e de atualização.

Uso de autenticação de pares de chaves

O Snowflake suporta o uso da autenticação de par de chaves em vez da típica autenticação por nome de usuário/senha ao chamar o ponto de extremidade de token OAuth. Este método de autenticação requer um par de chaves RSA de 2048 bits (mínimo). Gere o par de chaves pública-privada PEM (Privacy Enhanced Mail) usando OpenSSL. A chave pública é atribuída ao usuário do Snowflake que usa o cliente Snowflake.

Para configurar o par de chaves pública/privada:

  1. A partir da linha de comando em uma janela terminal, gere uma chave privada criptografada:

    $ openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 des3 -inform PEM -out rsa_key.p8
    
    Copy

    O OpenSSL solicita uma senha usada para criptografar o arquivo de chave privada. O Snowflake recomenda o uso de uma senha forte para proteger a chave privada. Registre esta senha. Você deve inseri-la ao conectar-se ao Snowflake. Note que a senha é usada apenas para proteger a chave privada e nunca é enviada ao Snowflake.

    Exemplo de chave privada PEM

    -----BEGIN ENCRYPTED PRIVATE KEY-----
    MIIE6TAbBgkqhkiG9w0BBQMwDgQILYPyCppzOwECAggABIIEyLiGSpeeGSe3xHP1
    wHLjfCYycUPennlX2bd8yX8xOxGSGfvB+99+PmSlex0FmY9ov1J8H1H9Y3lMWXbL
    ...
    -----END ENCRYPTED PRIVATE KEY-----
    
    Copy
  2. A partir da linha de comando, gere a chave pública, referenciando a chave privada:

    $ openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub
    
    Copy

    Exemplo de chave pública PEM

    -----BEGIN PUBLIC KEY-----
    MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy+Fw2qv4Roud3l6tjPH4
    zxybHjmZ5rhtCz9jppCV8UTWvEXxa88IGRIHbJ/PwKW/mR8LXdfI7l/9vCMXX4mk
    ...
    -----END PUBLIC KEY-----
    
    Copy
  3. Copie os arquivos de chaves públicas e privadas em um diretório local para armazenamento. Registre o caminho para os arquivos.

    Observe que a chave privada é armazenada usando o formato PKCS8 (Public Key Cryptography Standards) e é criptografada usando a senha especificada no passo anterior; entretanto, o arquivo ainda deve ser protegido contra acesso não autorizado usando o mecanismo de permissão de arquivo fornecido por seu sistema operacional. É sua responsabilidade proteger o arquivo quando ele não estiver sendo usado.

  4. Atribua a chave pública ao objeto de integração usando ALTERSECURITYINTEGRATION. Por exemplo:

    ALTER SECURITY INTEGRATION myint SET OAUTH_CLIENT_RSA_PUBLIC_KEY='MIIBIjANBgkqh...';
    
    Copy

    Nota

    • Somente os administradores de conta podem executar o comando ALTER SECURITY INTEGRATION.

    • Exclua o cabeçalho e rodapé da chave pública no comando.

    Verifique a impressão digital da chave pública usando DESCRIBE INTEGRATION:

    DESC SECURITY INTEGRATION myint;
    
    +----------------------------------+---------------+----------------------------------------------------------------------+------------------+
    | property                         | property_type | property_value                                                       | property_default |
    |----------------------------------+---------------+----------------------------------------------------------------------+------------------|
    ...
    | OAUTH_CLIENT_RSA_PUBLIC_KEY_FP   | String        | SHA256:MRItnbO/123abc/abcdefghijklmn12345678901234=                  |                  |
    | OAUTH_CLIENT_RSA_PUBLIC_KEY_2_FP | String        |                                                                      |                  |
    ...
    +----------------------------------+---------------+----------------------------------------------------------------------+------------------+
    
    Copy

    Nota

    A propriedade OAUTH_CLIENT_RSA_PUBLIC_KEY_2_FP está descrita em Rodízio de chaves (neste tópico).

  5. Modifique e execute o código de exemplo abaixo. O código usa a chave privada para codificar um JWT e depois passa esse token para o servidor de autorização do Snowflake:

    • Atualize os parâmetros de segurança:

      • <private_key>: abra o arquivo rsa_key.p8 em um editor de texto e copie as linhas entre o cabeçalho BEGIN e o rodapé END.

    • Atualize os parâmetros da sessão:

      • <account_identifier>: Especifica o nome completo de sua conta (fornecido pelo Snowflake).

    • Atualize os campos JSON Web Token (JWT):

      post body

      Um objeto JSON com os seguintes campos padrão (“declarações”):

      Atributo

      Tipo de dados

      Obrigatório

      Descrição

      iss

      Cadeia de caracteres

      Sim

      Especifica a entidade de segurança que emitiu o JWT no formato client_id.public_key_fp onde client_id é a ID de cliente da integração do cliente OAuth e public_key_fp é a impressão digital da chave pública que é usada durante a verificação.

      sub

      Cadeia de caracteres

      Sim

      Assunto do JWT no formato account_identifier.client_id onde account_identifier é o nome completo de sua conta Snowflake e client_id é a ID de cliente da integração do cliente OAuth. Dependendo da plataforma de nuvem (AWS ou Azure) e da região onde sua conta está hospedada, o nome completo da conta pode exigir segmentos adicionais. Para obter mais informações, consulte a descrição da variável account em Ponto de extremidade de token.

      iat

      Carimbo de data/hora

      Não

      Hora em que o token foi emitido.

      exp

      Carimbo de data/hora

      Sim

      Hora em que o token deve expirar. Este período deve ser relativamente curto (por exemplo, alguns minutos).

    Código de exemplo

    Observe que o valor private_key inclui o cabeçalho -----BEGIN e o rodapé -----END.

    import datetime
    import json
    import urllib
    
    import jwt
    import requests
    
    private_key = """
    <private_key>
    """
    
    public_key_fp = "SHA256:MR..."
    
    
    def _make_request(payload, encoded_jwt_token):
        token_url = "https://<account_identifier>.snowflakecomputing.com/oauth/token-request"
        headers = {
                u'Authorization': "Bearer %s" % (encoded_jwt_token),
                u'content-type': u'application/x-www-form-urlencoded'
        }
        r = requests.post(
                token_url,
                headers=headers,
                data=urllib.urlencode(payload))
        return r.json()
    
    
    def make_request_for_access_token(oauth_az_code, encoded_jwt_token):
        """ Given an Authorization Code, make a request for an Access Token
        and a Refresh Token."""
        payload = {
            'grant_type': 'authorization_code',
            'code': oauth_az_code
        }
        return _make_request(payload, encoded_jwt_token)
    
    
    def make_request_for_refresh_token(refresh_token, encoded_jwt_token):
        """ Given a Refresh Token, make a request for another Access Token."""
        payload = {
            'grant_type': 'refresh_token',
            'refresh_token': refresh_token
        }
        return _make_request(payload, encoded_jwt_token)
    
    
    def main():
        account_identifier = "<account_identifier>"
        client_id = "1234"  # found by running DESC SECURITY INTEGRATION
        issuer = "{}.{}".format(client_id, public_key_fp)
        subject = "{}.{}".format(account_identifier, client_id)
        payload = {
            'iss': issuer,
            'sub': subject,
            'iat': datetime.datetime.utcnow(),
            'exp': datetime.datetime.utcnow() + datetime.timedelta(seconds=30)
        }
        encoded_jwt_token = jwt.encode(
                payload,
                private_key,
                algorithm='RS256')
    
        data = make_request_for_access_token(oauth_az_code, encoded_jwt_token)
        refresh_token = data['refresh_token']
        data = make_request_for_refresh_token(refresh_token, encoded_jwt_token)
        access_token = data['access_token']
    
    
    if __name__ == '__main__':
        main()
    
    Copy

    Após a criação do token, envie-o em solicitações ao ponto de extremidade de token. As solicitações exigem o formato de autorização Bearer como o cabeçalho da autorização, em vez do formato básico de autorização normalmente usado para ID de cliente e segredo do cliente, como se segue:

    "Authorization: Bearer JWT_TOKEN"
    
    Copy

Rotação de chaves

O Snowflake suporta múltiplas chaves ativas para permitir rodízio ininterrupto. Alterne e substitua suas chaves públicas e privadas com base no cronograma de vencimento que você segue internamente.

Atualmente, é possível usar os parâmetros OAUTH_CLIENT_RSA_PUBLIC_KEY e OAUTH_CLIENT_RSA_PUBLIC_KEY_2 para ALTERSECURITYINTEGRATION para associar até 2 chaves públicas com um único usuário.

Para alternar suas chaves:

  1. Complete as etapas em Uso de autenticação de pares de chaves (neste tópico):

    • Gere um novo conjunto de chaves privada e pública.

    • Atribua a chave pública à integração. Defina o valor da chave pública para OAUTH_CLIENT_RSA_PUBLIC_KEY ou OAUTH_CLIENT_RSA_PUBLIC_KEY_2 (o valor de chave que não esteja em uso no momento). Por exemplo:

      alter integration myint set oauth_client_rsa_public_key_2='JERUEHtcve...';
      
      Copy
  2. Atualize o código para conectar ao Snowflake. Especifique a nova chave privada.

    O Snowflake verifica a chave pública ativa correta para autenticação com base na chave privada apresentada.

  3. Remova a antiga chave pública da integração. Por exemplo:

    alter integration myint unset oauth_client_rsa_public_key;
    
    Copy

Códigos de erro

Consulte em Códigos de erro uma lista de códigos de erro associados ao OAuth, bem como erros que são retornados no blob JSON, durante o fluxo de autorização, solicitação ou troca de tokens ou ao criar uma sessão do Snowflake após completar o fluxo OAuth.