Pular para o conteúdo principal
Antes de criar um cliente, é necessário estar autorizado na Vantage API. Consulte Autenticação para mais detalhes.

​
Criando um Client

Para criar um client, você precisará enviar uma solicitação POST com o cabeçalho Authorization = Bearer <access token> para {baseUrl}/api/adminapi2/v1/tenants/{tenantId}/clients/ com os seguintes parâmetros no corpo da solicitação:
ParameterDescription
clientIdO identificador do client.
clientNameO nome do client (por exemplo, o nome do seu app).
allowOfflineAccessEspecifica se um refresh token será gerado junto com o access token, que o aplicativo pode usar para atualizar automaticamente o access token sem intervenção do usuário. Definido como False por padrão.
allowRememberConsentEspecifica se o usuário pode optar por armazenar decisões de consentimento. Definido como True por padrão.
backChannelLogoutSessionRequiredEspecifica se o mecanismo de Backchannel Logout é obrigatório. Definido como True por padrão.
requireClientSecretEspecifica se um client secret é obrigatório. Definido como True por padrão.
requireConsentEspecifica se uma tela de consentimento é obrigatória. Definido como False por padrão.
allowNoPkceEspecifica se o esquema de autenticação Authorization Code Flow with Proof Key for Code Exchange (PKCE) é permitido. Definido como False por padrão, permitindo apenas o esquema de autenticação Authorization Code Flow with Proof Key for Code Exchange (PKCE).
allowedGrantTypesEspecifica os tipos de concessão (grant types) que podem ser usados.
allowedCorsOriginsEspecifica se o mecanismo padrão de Cross-Origin Resource Sharing (CORS) é usado.
allowedScopesDefine o conjunto de recursos e dados do usuário que devem ser transferidos no token. O valor do escopo deve ser exatamente “openid permissions publicapi.all”.
postLogoutRedirectUrisUma lista de URIs permitidas para redirecionamento após o logout.
redirectUrisUma lista de sites ou URLs de apps em whitelist para redirecionamentos do token de autorização. Prefixos são permitidos para a URL. Se o prefixo corresponder, qualquer URL será permitida, por exemplo: [ “https://myDomain.”, “https://myApp.myDomain.com/oauth-signin.html” ].
Importante! Ao autenticar usando Resource Owner Password Credentials, você deve definir o parâmetro allowRopc como TRUE. Observe que esse esquema de autenticação pressupõe que o usuário envie suas credenciais para o aplicativo; portanto, recomenda-se usar ROPC apenas se um client confidencial confiável estiver autenticado. Exemplo de solicitação:

​
No Windows

curl --location --request POST "{baseUrl}/api/adminapi2/v1/tenants/{tenantId}/clients/" 
-H "accept: application/json" \
-H "Authorization: Bearer {token}"
{ 
  "clientId": "{clientId}",
  "clientName": "{clientName}", 
  "allowOfflineAccess": true,
  "allowRememberConsent": true,
  "backChannelLogoutSessionRequired": true,
  "requireClientSecret": true,    
  "requireConsent": false,  
  "allowNoPkce": true, 
  "allowedGrantTypes": [    
    "{allowedGrantTypes}"  
  ],
  "allowedCorsOrigins": [
    "{allowedCorsOrigins}"
  ],
  "allowedScopes": [ 
    "openid",
    "permissions",
    "publicapi.all" 
  ] 
  "postLogoutRedirectUris": [
     "{postLogoutRedirectUris}"
  ], 
  "redirectUris": [ 
    "{redirectUris}" 
  ]
}

​
No Linux

curl --location --request POST '{baseUrl}/api/adminapi2/v1/tenants/{tenantId}/clients/'
-H 'accept: application/json' \
-H 'Authorization: Bearer {token}'
{ 
  'clientId': '{clientId}',
  'clientName': '{clientName}', 
  'allowOfflineAccess': true,
  'allowRememberConsent': true,
  'backChannelLogoutSessionRequired': true,
  'requireClientSecret': true,    
  'requireConsent': false,  
  'allowNoPkce': true, 
  'allowedGrantTypes': [    
    '{allowedGrantTypes}'  
  ],
  'allowedCorsOrigins': [
    '{allowedCorsOrigins}'
  ],
  'allowedScopes': [ 
    'openid',
    'permissions',
    'publicapi.all' 
  ] 
  'postLogoutRedirectUris': [
     '{postLogoutRedirectUris}'
  ], 
  'redirectUris': [ 
    '{redirectUris}' 
  ]
}
A resposta do servidor incluirá uma descrição do cliente criado.

​
Criando um segredo

Cada cliente pode ter vários segredos. Isso permite que o cliente passe a usar um novo segredo quando o atual expirar, sem precisar excluí-lo. Por padrão, um segredo de cliente expira após seis meses. Para criar um segredo, envie uma solicitação POST com o cabeçalho Authorization = Bearer <access token> para {baseUrl}/api/adminapi2/v1/tenants/{tenantId}/clients/{clientId}/secrets/ com os seguintes parâmetros no corpo da solicitação:
ParameterDescription
descriptionUma descrição do segredo do cliente. Pode ser um comentário curto para ajudar você a diferenciar os segredos. Este parâmetro é opcional.
start timeEspecifica a data de início do segredo.
expirationEspecifica a data de expiração do segredo (entre 1 dia e 3 anos). Por exemplo, “2021-09-07T13:03:38.380Z”. Por padrão, essa data é definida para exatamente seis meses a partir da criação do segredo.
Exemplo de solicitação:

​
No Windows

curl --location --request POST "{baseUrl}/api/adminapi2/v1/tenants/{tenantId}/clients/{clientId}/secrets/"
-H "accept: application/json" \
-H "Authorization: Bearer {token}"
-H "Content-Type: application/json-patch+json" \ 
-d 
{ 
  "description": "{description}",
  "startTime": "{startTime}"
  "expiration": "{expiration}" 
}

​
No Linux

curl --location --request POST '{baseUrl}/api/adminapi2/v1/tenants/{tenantId}/clients/{clientId}/secrets/'
-H 'accept: application/json' \
-H 'Authorization: Bearer {token}'
-H 'Content-Type: application/json-patch+json' \ 
-d 
{ 
  'description': '{description}',
  'startTime': '{startTime}'
  'expiration': '{expiration}' 
}
A resposta do servidor à sua solicitação conterá um segredo do cliente (value) e seu período de validade (startTime, expiration). Importante! O valor do segredo do cliente só estará disponível no momento da criação. Armazene-o em um local seguro para evitar perder o acesso ao cliente por meio desse segredo. Depois, você só poderá visualizar os três primeiros caracteres do valor do segredo do cliente (valueDisplay).