Pular para o conteúdo principal

🔑 Autenticação e Credenciais de Acesso

Para utilizar as APIs da Credsystem é necessário se autenticar usando o token de acesso obtido através do sistema de autenticação OAuth2.

O sistema de autenticação OAuth2 da Credsystem suporta a interação server-to-server entre uma aplicação web e os serviços da Credsystem. Para este cenário, você precisa de uma conta de serviço, que é uma conta impessoal que pertence à sua aplicação e não a um usuário individual. Administradores poderão solicitar que uma conta de serviço possa ter autorização para acessar dados de uma conta de usuário.

Para mais detalhes de como uma aplicação pode completar o processo de autenticação OAuth2 server-to-server através do protocolo HTTP, consulte este guia de Autenticação.

É obrigatório enviar o token obtido no header de suas requisições através da chave Authorization.

⚠️ Segurança Crítica

NUNCA exponha suas credenciais (client_id e client_secret) em código client-side (frontend, aplicativos móveis) ou em repositórios públicos. Estas credenciais devem ser armazenadas exclusivamente em servidores backend seguros.

📌 Importante

Os tokens JWT possuem tempo de expiração limitado. Implemente um sistema de renovação automática de tokens quando necessário. Tokens expirados retornarão erro 401 Unauthorized.


📋 Como Solicitar Credenciais

🌐 Solicitação pelo Portal do Desenvolvedor

A forma oficial de solicitar suas credenciais de API é através do nosso Portal do Desenvolvedor:

Processo de Solicitação:

  1. Acesse o Portal - Faça login no Portal do Desenvolvedor Credsystem
  2. Preencha o Formulário - Clique no botão acima e preencha:
    • E-mail corporativo (preenchido automaticamente)
    • E-mail do contato comercial responsável
    • APIs que deseja acessar
    • Ambiente (Homologação ou Produção)
    • Justificativa de negócio
  3. Aguarde Aprovação - Sua solicitação será analisada em até 72 horas úteis
  4. Receba os E-mails - Após aprovação, você receberá:
    • Convite do SharePoint com documentação técnica (primeiro)
    • E-mail com credenciais (Client ID e Secret)

📧 E-mails que Você Receberá

Após a aprovação da sua solicitação, você receberá dois e-mails importantes nesta ordem:

1️⃣ Convite do SharePoint (Primeiro)

Assunto: Credenciais de API - Portal do Desenvolvedor Credsystem

Conteúdo do e-mail:

Olá [Seu Nome],

Você foi convidado para acessar a documentação técnica da Credsystem no SharePoint!

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📂 ACESSO AO SHAREPOINT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[Botão: Aceitar Convite]

Este convite expira em 30 dias.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Dúvidas? Entre em contato:
📧 suporte.tecnico@credsystem.com.br
🌐 https://desenvolvedor.credsystem.com.br

Atenciosamente,
Equipe Credsystem

2️⃣ E-mail com Credenciais de API (Após aceitar o convite)

Assunto: Credenciais de API - Portal do Desenvolvedor Credsystem

Conteúdo do e-mail:

Olá [Seu Nome],

Suas credenciais para acesso às APIs da Credsystem foram aprovadas!

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔐 CREDENCIAIS DE ACESSO
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Ambiente: [Homologação/Produção]

Client ID: af9c9e3ca3aa4390b86083ebe5f60449
Client Secret: 5a948d61-c135-4671-9d6a-d0a2324b97e2

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📚 APIs APROVADAS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

✓ Autenticação OAuth 2.0
✓ Venda em Loja Física
✓ Arrecadação em Loja v2
[... outras APIs aprovadas]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Dúvidas? Entre em contato:
📧 suporte.tecnico@credsystem.com.br
🌐 https://desenvolvedor.credsystem.com.br

Atenciosamente,
Equipe Credsystem
💡 Importante

Você receberá dois e-mails separados nesta ordem:

  1. Convite SharePoint (primeiro) - aceite para acessar documentação técnica completa
  2. Credenciais de API (segundo) - Client ID e Secret para começar a integração

📋 Checklist de Recebimento

Após solicitar suas credenciais, verifique se recebeu:

  • ✅ Convite do SharePoint para documentação técnica
  • ✅ E-mail com Client ID e Client Secret

Não recebeu algum dos e-mails?

  • Verifique sua pasta de spam/lixo eletrônico
  • Aguarde até 72 horas úteis após a solicitação
  • Entre em contato com seu representante comercial da Credsystem

🔐 Sistemas de Autenticação

A Credsystem oferece dois sistemas de autenticação OAuth2 dependendo do tipo de integração:

1️⃣ Red Hat SSO (Keycloak)

Usado para a maioria das APIs da Credsystem. Suporta três fluxos de autenticação:

🔑 Client Credentials Grant (Máquina-a-Máquina)

Quando usar:

  • Integração entre sistemas backend
  • APIs de servidor para servidor
  • Jobs automatizados e processos batch
  • Microserviços

Características:

  • ✅ Sem envolvimento de usuário
  • ✅ Ideal para aplicações server-side
  • ✅ Token de curta duração (300 segundos)
  • ✅ Renovação automática disponível

👤 Password Grant (Usuário e Senha)

Quando usar:

  • Aplicações web com login de usuário
  • Apps móveis com tela de autenticação
  • Cenários onde o usuário fornece credenciais diretamente

Características:

  • ✅ Autenticação com username e password
  • ✅ Access token + Refresh token
  • ✅ Ideal para aplicações com usuários finais

🔄 Refresh Token

Quando usar:

  • Access token expirou (erro 401)
  • Manter usuário logado sem redigitar senha
  • Renovação proativa antes da expiração

Características:

  • ✅ Renovação sem nova autenticação
  • ✅ Mantém sessão ativa
  • ✅ Refresh token válido por 1800 segundos

2️⃣ Oracle IDCS (Identity Cloud Service)

Usado especificamente para integrações com redes credenciadas.

Quando usar:

  • Integração com aplicações Oracle
  • APIs de redes credenciadas parceiras
  • Autenticação para lojas físicas específicas

Características:

  • ✅ Autenticação via Basic Auth
  • ✅ Scope específico por loja/rede
  • ✅ Client Credentials Grant
  • ✅ Token com validade configurável

📝 Exemplos de Autenticação

Red Hat SSO - Client Credentials

curl -X POST "https://sso.credsystem.com.br/auth/realms/credsystem/protocol/openid-connect/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials" \
-d "client_id=SEU_CLIENT_ID" \
-d "client_secret=SEU_CLIENT_SECRET"

Red Hat SSO - Password Grant

curl -X POST "https://sso.credsystem.com.br/auth/realms/credsystem/protocol/openid-connect/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=password" \
-d "client_id=SEU_CLIENT_ID" \
-d "client_secret=SEU_CLIENT_SECRET" \
-d "username=usuario@exemplo.com" \
-d "password=SenhaSegura123!" \
-d "scope=openid profile email"

Red Hat SSO - Refresh Token

curl -X POST "https://sso.credsystem.com.br/auth/realms/credsystem/protocol/openid-connect/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=refresh_token" \
-d "client_id=SEU_CLIENT_ID" \
-d "client_secret=SEU_CLIENT_SECRET" \
-d "refresh_token=SEU_REFRESH_TOKEN"

Oracle IDCS - Client Credentials

# Exemplo para LOJA-A
curl -X POST "https://idcs-0fe1bec59571471484a8896c1a0d7a62.identity.oraclecloud.com/oauth2/v1/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-H "Authorization: Basic BASE64_CLIENT_ID_SECRET" \
-d "grant_type=client_credentials" \
-d "scope=LOJA-A-HML-cc3e9c9b-7d64-4ff3-a86a-1d7teste19ac13"
Gerando Basic Auth

O header Authorization: Basic deve conter client_id:client_secret em Base64:

echo -n "client_id:client_secret" | base64

🔒 Segurança e Boas Práticas

⚠️ Segurança Crítica

NUNCA exponha suas credenciais (client_id e client_secret) em:

  • ❌ Código client-side (frontend, aplicativos móveis)
  • ❌ Repositórios públicos (GitHub, GitLab, etc.)
  • ❌ Logs ou mensagens de erro
  • ❌ URLs ou query parameters

Armazene credenciais exclusivamente em servidores backend seguros

✅ Checklist de Segurança

  • Credenciais armazenadas em variáveis de ambiente
  • Comunicação sempre via HTTPS
  • Tokens armazenados de forma segura (nunca em localStorage)
  • Sistema de renovação automática de tokens implementado
  • Tratamento adequado de erros 401 (Unauthorized)
  • Logout implementado para invalidar tokens
  • Rotação periódica de credenciais
  • Monitoramento de uso de tokens
  • Rate limiting implementado
  • Logs de autenticação para auditoria

⏱️ Gerenciamento de Tokens

Tipo de TokenValidade PadrãoAção Recomendada
Access Token (Keycloak)300s (5 min)Renovar automaticamente
Refresh Token (Keycloak)1800s (30 min)Usar para renovação
Access Token (IDCS)ConfigurávelVerificar no response
📌 Importante

Os tokens JWT possuem tempo de expiração limitado. Implemente um sistema de renovação automática de tokens quando necessário. Tokens expirados retornarão erro 401 Unauthorized.


⚡ Problemas Comuns

❌ Erro 401 - Unauthorized

Possíveis causas:

  • Token expirado
  • Credenciais inválidas
  • Client ID ou Secret incorretos
  • Realm incorreto

Solução:

  1. Verifique se as credenciais estão corretas
  2. Tente renovar o token com refresh_token
  3. Verifique se o realm está correto na URL
  4. Confirme que o token está sendo enviado no header Authorization: Bearer <token>
❌ Erro 400 - Bad Request

Possíveis causas:

  • Parâmetros obrigatórios faltando
  • Formato incorreto do body
  • grant_type inválido

Solução:

  1. Verifique todos os parâmetros obrigatórios
  2. Confirme que o Content-Type é application/x-www-form-urlencoded
  3. Valide o grant_type (deve ser: client_credentials, password ou refresh_token)
❌ Erro 403 - Forbidden

Possíveis causas:

  • Client sem permissões necessárias
  • Scope não autorizado
  • Ambiente incorreto

Solução:

  1. Verifique se o client tem as roles necessárias
  2. Confirme que está usando o ambiente correto (homologação/produção)
  3. Entre em contato com o suporte para revisar permissões

🔄 Próximos Passos

Agora que você tem suas credenciais e sabe como se autenticar:

  1. 📖 Explore as APIs disponíveis
  2. 🏗️ Veja exemplos de integração
  3. 🧪 Teste em Homologação
  4. 🚀 Boas praticas