Overview

Ainda não implementado. Esta página descreve o design alvo, não um serviço em produção. Hoje o checklist-mobile fala diretamente com o license-manager — é essa comunicação direta que o key-service vai substituir quando for construído.

Problema que resolve

Toda aplicação da empresa (ERP, frota, gestão de pneus, e o que vier depois) precisa validar se o cliente que a está rodando tem direito de usar aquele software, em qual plano, e com quais limites. Sem um serviço central para isso, cada software reimplementa autenticação de licença do zero, e cada implementação vira uma superfície de fraude diferente.

Separação de responsabilidades

Duas peças, papéis diferentes:

• license-manager (Laravel) — backoffice, fonte da verdade de negócio: quem é o cliente, qual plano ele comprou, quais produtos ele tem direito, cadastro de catálogo. Tem painel. No estado alvo, deixa de expor API para o software do cliente em produção — só fala com o key-service.
• key-service (Go) — único ponto de contato dos softwares instalados no cliente. Emite voucher, ativa certificado, entrega o token de licença, revoga quando preciso. O license-manager avisa o key-service quando um cliente é criado ou um produto é vinculado; a partir daí o key-service atende esse cliente sozinho.

O software instalado no cliente nunca fala com o license-manager. Fala só com o key-service. Mecanismo de ativação e PKI em pki-and-activation; formato do token e propagação de evento em tokens-and-events.

Por que qualquer software pode usar o mesmo serviço

O mecanismo de autenticação (certificado + token) não precisa saber o que está rodando do outro lado. Resolve só duas perguntas: esse cliente é quem diz ser, e o que esse cliente tem direito de usar.

A resposta da segunda pergunta vem de um catálogo cadastrável, não de um tipo de aplicação embutido no código:

• Software — cadastrado no catálogo (erp, frota, gestão de pneus, o próximo).
• Plano — preset de entitlements e limites. Tier e plano são a mesma entidade.
• Entitlement — cada capacidade interna de um software (ex.: no frota, “caminhões”, “implementos”, “alertas”) é uma chave de entitlement. A lógica de “o que essa tela mostra” fica do lado do software; o key-service só entrega os fatos.
• Limite — catálogo de tipos de limite, hierarquia de um nível só. Sem billing por consumo na v1: o software se autofiscaliza pelo teto que vem no token.

Instalar “ERP versão básica” ou “ERP versão completa” é o mesmo software com planos diferentes, não dois builds diferentes. Quando um software novo entra no catálogo, não precisa de mudança no key-service — só cadastro de software, plano e entitlements no license-manager.