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:
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.
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
...
';
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 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
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
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 |
---|---|---|---|
|
Cadeia de caracteres |
Sim |
ID do cliente da integração. |
|
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 |
---|---|---|---|
|
Cadeia de caracteres |
Sim |
Tipo de concessão solicitada: . |
|
Cadeia de caracteres |
Sim |
Código de autorização retornado do ponto de extremidade de token. Usado e exigido quando |
|
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 |
|
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 |
|
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 |
Resposta¶
Um objeto JSON é retornado com os seguintes campos:
Campo |
Tipo de dados |
Descrição |
---|---|---|
|
Cadeia de caracteres |
Token de acesso utilizada para estabelecer uma sessão do Snowflake |
|
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 |
|
Inteiro |
Número de segundos restantes até que o token expire |
|
Cadeia de caracteres |
Tipo de token de acesso. Atualmente, sempre |
|
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",
}
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"
}
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:
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.
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)))
.
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.
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.Snowflake transforma o valor
code_verifier
e verifica se o valor transformado corresponde ao valorcode_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:
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
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-----
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
Exemplo de chave pública PEM
-----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy+Fw2qv4Roud3l6tjPH4 zxybHjmZ5rhtCz9jppCV8UTWvEXxa88IGRIHbJ/PwKW/mR8LXdfI7l/9vCMXX4mk ... -----END PUBLIC KEY-----
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.
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...';
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 | | | ... +----------------------------------+---------------+----------------------------------------------------------------------+------------------+
Nota
A propriedade
OAUTH_CLIENT_RSA_PUBLIC_KEY_2_FP
está descrita em Rodízio de chaves (neste tópico).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 arquivorsa_key.p8
em um editor de texto e copie as linhas entre o cabeçalhoBEGIN
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
ondeclient_id
é a ID de cliente da integração do cliente OAuth epublic_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
ondeaccount_identifier
é o nome completo de sua conta Snowflake eclient_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ávelaccount
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()
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"
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:
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
ouOAUTH_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...';
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.
Remova a antiga chave pública da integração. Por exemplo:
alter integration myint unset oauth_client_rsa_public_key;
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.