Conexão Clube AGB

Ela permite entrar em apps, jogos e integrações usando sua conta do Clube AGB, sem criar uma senha nova em cada lugar.

Porque seu jogador chega com uma conta conhecida, reduzindo cadastro repetido e facilitando comunidade, rankings, eventos, testes fechados e áreas de membros.

Não. Ela foi pensada com carinho para jogos em áudio, mas também pode atender games educacionais, narrativos, casuais, competitivos, ferramentas, comunidades e projetos digitais com qualquer finalidade legítima.

Pode. A proposta incentiva acessibilidade, mas não limita a API somente a projetos acessíveis. Ela pode ajudar qualquer criador que queira um login organizado.

Sim. Projetos pequenos ganham simplicidade desde cedo e evitam refazer autenticação quando crescerem.

Faz sentido como opção adicional. O usuário pode escolher entrar pelo Clube AGB quando isso for mais conveniente.

Não. A senha fica no Clube AGB. A integração parceira não recebe, não vê e não armazena a senha do membro.

Não. Nem o administrador master tem acesso à senha real. A senha é protegida para validação de entrada, não para leitura por pessoas.

O sistema valida a entrada usando uma versão protegida da senha. Essa verificação confirma o acesso sem revelar a senha original.

Não. Ela recebe apenas os dados autorizados pelo usuário e permitidos pelo aplicativo cadastrado.

Pode. A autorização é uma escolha do usuário. Se ele negar, a integração parceira não recebe o acesso.

Não. Ela só facilita a entrada. A comunidade, as regras, as conquistas e a experiência continuam sendo do seu projeto.

Sim. A conta do Clube AGB pode ajudar a identificar participantes, reduzir duplicidade e simplificar entrada em eventos.

Sim. Um criador pode liberar áreas internas do seu projeto para membros autenticados.

Sim. Jogos de estudo, cursos, desafios, leitura, treino, memória, idiomas ou matemática podem usar a conexão como porta de entrada.

Sim. Aventuras textuais, áudio dramas interativos e RPGs narrativos podem aproveitar identidade unificada.

Sim, desde que o uso respeite os usuários e a finalidade do Clube AGB. Comunidades, ferramentas e portais também podem se beneficiar.

Não. Ela funciona como uma ponte de login. Seu projeto continua independente.

Ele encontra um botão para entrar com a conta do Clube AGB, autoriza o acesso e segue para o app, jogo ou integração.

Não. A integração recebe autorização, não a senha.

Não. Se um app, jogo ou site pedir sua senha do Clube AGB diretamente, desconfie. A integração correta não precisa disso.

A tela de autorização mostra o app solicitante e os dados pedidos. Confira antes de aceitar.

Sim. O usuário pode encerrar o vínculo quando não quiser manter a conexão com um projeto parceiro.

Sim, desde que tenha acesso ao painel e siga os exemplos técnicos disponíveis na área reservada.

Ajuda porque cria uma forma comum de entrada, com autorização explícita e sem espalhar senhas.

Pode, quando a integração estiver funcionando corretamente no seu app, jogo ou site.

A intenção da conexão é reduzir barreiras de entrada para o usuário. Qualquer custo do projeto parceiro é definido pelo próprio criador fora do login.

Sim. Jogos gratuitos são um caso natural para esse tipo de login.

Sim, desde que o fluxo de pagamento e acesso seja responsabilidade clara do projeto parceiro.

Não. Ela autentica e identifica conforme autorização. As regras do jogo são do criador.

Não automaticamente. Mas facilita que projetos acessíveis encontrem uma base de usuários e que criadores pensem em entrada simples para todos.

Games em áudio dependem muito de comunidade, confiança e descoberta. Uma conexão centralizada reduz atrito entre criador e jogador.

Não. O visual e a experiência do seu projeto continuam sendo seus.

Não por padrão. A conexão é de login e autorização, não de edição do seu conteúdo.

O criador pode revisar seu cadastro, ajustar retorno e desativar acessos quando necessário.

Entre no painel de parceiros, cadastre o aplicativo, informe as URLs de retorno e escolha somente os escopos necessários.

É útil entender requisições HTTP, sessões, variáveis de ambiente e o fluxo de autorização. Os exemplos reduzem o trabalho inicial.

O painel gera as credenciais ao concluir um cadastro válido. Regras administrativas adicionais podem depender da política do Clube.

Sim. Cada projeto pode ter credenciais, URLs, escopos e ciclo de vida independentes.

Prefira clientes separados para reduzir risco, distinguir logs e impedir que URLs de teste sejam usadas em produção.

Não. A integração usa HTTPS e JSON. Você pode usar o SDK, os exemplos ou qualquer biblioteca HTTP adequada à sua linguagem.

Desative o aplicativo, revogue tokens e remova com segurança credenciais e sessões que não serão mais utilizadas.

Sim. Há um exemplo em GDScript para Godot com requisições assíncronas e sinais de sucesso ou falha.

Sim. Jogos web podem usar o backend seguro e o exemplo com fetch, respeitando HTTPS e a configuração restrita de CORS.

Não. O segredo fica no backend do criador. O executável do jogo recebe somente uma sessão própria do jogo.

Não é recomendado. Apps distribuídos podem ser inspecionados, portanto devem usar um backend que proteja o segredo.

Nos exemplos recomendados para jogos, não. O backend usa o token da API e entrega ao jogo somente uma sessão própria.

Ele consulta temporariamente o backend com um identificador e um segredo de polling até receber sucesso, recusa, erro ou expiração.

Não quando é feito no intervalo recomendado e em segundo plano. Os exemplos evitam bloquear renderização, áudio e interface.

A tentativa permanece pendente até expirar. O jogo pode informar o tempo esgotado e oferecer uma nova tentativa.

O backend informa a recusa ao aplicativo sem criar sessão nem compartilhar dados do usuário.

O código é temporário, expira rapidamente e só pode ser utilizado uma vez.

Não necessariamente. O parceiro pode criar um perfil local automaticamente ou vincular a identidade do Clube a uma conta existente.

Sim. Cada projeto recebe uma autorização independente e somente os dados correspondentes aos seus escopos.

Sim. O projeto pode manter apelido ou nome de exibição próprio, preservando o id do Clube como vínculo estável.

Não. A conta do projeto parceiro e a conta central são independentes, salvo política claramente informada ao usuário.

Negue novas sessões e siga a resposta da API. O projeto deve encerrar ou limitar sessões locais conforme sua política.

Pode, mas avalie se áreas públicas realmente precisam de autenticação e explique claramente essa exigência.

Encerre a sessão local e a autorização atual antes de iniciar um novo login no navegador com a conta desejada.

Use somente em ambiente local controlado quando necessário. Em produção, a URL de retorno e todo o fluxo devem usar HTTPS.

É um valor aleatório ligado à tentativa de login, usado para confirmar que o callback pertence ao fluxo iniciado.

Não. Cada tentativa deve gerar um valor novo e apagá-lo da sessão depois do callback.

A API devolve erros JSON no campo erro. O parâmetro error é usado no callback quando o usuário recusa a autorização.

O escopo profile permite receber identificador, nome e nível do usuário.

O escopo email permite receber o endereço de e-mail quando ele foi solicitado, permitido e autorizado.

Não. Solicite somente os dados realmente necessários para a função oferecida pelo projeto.

Os escopos atuais são voltados à identificação e leitura dos dados permitidos, não à alteração da conta do Clube.

O campo id deve ser usado como identificador externo estável. Nome e e-mail podem ser atualizados pelo usuário.

Não é o ideal. Use o id da API como vínculo principal e trate o e-mail como um dado atualizável.

O fluxo usa informações técnicas necessárias à segurança e operação, como endereço de rede e agente do navegador, conforme a política aplicável.

Não deve usar dados fora da finalidade informada e autorizada. Qualquer tratamento precisa respeitar consentimento, política e legislação aplicável.

Somente pelo período necessário à finalidade declarada, com política de retenção, atualização e exclusão.

O parceiro deve oferecer canal e procedimento próprios, pois ele controla os dados armazenados em seu sistema.

Não. Ela encerra o acesso da integração. O parceiro ainda deve cumprir sua política de exclusão dos dados já armazenados.

Guarde somente os campos necessários. Evite duplicar dados que não serão usados e mantenha-os atualizados.

Explique quem opera o projeto, quais dados são pedidos, para qual finalidade, por quanto tempo e como revogar ou solicitar exclusão.

Depende das regras do Clube AGB e do projeto parceiro. O criador deve respeitar público, idade e segurança.

Sim. O ideal é testar em ambiente controlado antes de abrir para todos.

Sim. Criadores podem alinhar a finalidade do projeto, o público esperado e a melhor forma de apresentar a entrada pelo Clube AGB.

Não para clientes confidenciais desta API. PKCE protege o código e o client_secret autentica o backend; as duas proteções se complementam.

Use S256. O método plain não deve ser usado porque expõe o verificador de forma inadequada.

Use valor aleatório URL-safe entre 43 e 128 caracteres, com entropia suficiente e criado para uma única tentativa.

Não. Ele viaja na autorização. O segredo temporário é o code_verifier, mantido no backend até a troca.

Prefira sessão protegida no servidor. Se usar cookie, ele precisa de integridade, confidencialidade e atributos seguros adequados.

É a tentativa de fazer um cliente trocar um código associado a outra transação. PKCE ajuda a bloquear esse cenário.

Funções como hash_equals reduzem diferenças de tempo observáveis durante a comparação de valores sensíveis.

Assim que todas as integrações legítimas estiverem atualizadas. Se não houver clientes antigos, pode ser ativado desde o início.

Não. O consumo é atômico e uma segunda tentativa é rejeitada como código inválido ou já utilizado.

A resposta da API informa a duração em segundos. A integração deve respeitar essa expiração e não presumir duração infinita.

O backend de exemplo possui uma rota de logout que revoga imediatamente a sessão própria apresentada pelo jogo.

Sim. A área de tokens permite encerrar acessos que não sejam mais necessários.

É o identificador público do aplicativo cadastrado. Ele pode aparecer na URL de autorização.

É a credencial privada do aplicativo, usada somente pelo backend ao trocar o código por token.

Em variável de ambiente ou cofre de segredos do servidor, nunca no repositório, HTML, JavaScript público ou executável.

Gere um novo segredo no painel, atualize o ambiente do servidor e invalide o valor antigo imediatamente.

Sim. O painel aceita múltiplas URLs autorizadas, e cada requisição deve usar exatamente uma delas.

A correspondência exata impede que códigos de autorização sejam enviados para endereços não cadastrados.

Não com segurança, porque não possui backend privado para proteger o client_secret. Use um backend ou serviço intermediário controlado.

Sim. Implemente o fluxo em um plugin ou backend confiável, use as APIs de sessão do WordPress e não coloque segredos no tema público.

Sim. Use o cliente HTTP e o armazenamento de sessão do framework, mantendo state e PKCE vinculados à mesma tentativa.

A interface pode iniciar o login, mas a troca de token deve acontecer em backend seguro, preferencialmente com sessão HttpOnly.

Adote um padrão backend-for-frontend: o navegador usa sessão própria e o servidor realiza o OAuth e guarda credenciais.

Não. Pode usar redirecionamento na mesma aba ou janela auxiliar, desde que preserve sessão, state e experiência acessível.

Guarde internamente um destino permitido e valide-o antes do redirecionamento para evitar encaminhamento aberto a domínios externos.

Ela evita que cada projeto peça tudo de novo. O usuário entra com uma identidade já existente e autoriza somente o necessário.

Se você cria jogos em áudio, games acessíveis, jogos comuns, ferramentas ou comunidades, a Conexão Clube AGB pode ser a ponte entre seu projeto e uma base de membros pronta para entrar.

PKCE é uma proteção adicional que vincula o início do login à troca do código. A Conexão Clube AGB usa o método seguro S256.

Ele dificulta que um código de autorização interceptado seja usado por outra pessoa ou aplicação.

Não. A proteção acontece nos bastidores e não acrescenta etapas ao login do usuário.

Sim. Existe um exemplo em Python para Pygame que abre o navegador e acompanha o resultado sem travar a janela ou o áudio do jogo.

Sim. O SDK inclui um exemplo com janela wxPython e consulta em segundo plano para manter a interface responsiva.

Sim. Há um exemplo em C# para Unity usando recursos nativos do motor e abertura segura do navegador.

Sim. Associe o id do Clube ao perfil local e salve o progresso no backend do jogo.

Não. Ela fornece identidade. Conquistas, inventário, ranking e progresso continuam sob responsabilidade do jogo.

Sim. Valide a sessão própria no backend antes de permitir entrada em partidas ou serviços protegidos.

Não. O backend deve obter a identidade a partir de uma sessão válida, nunca de um id livre enviado pelo executável.

Abra o navegador padrão ou mostre URL e QR code para uma página segura vinculada à tentativa.

Sim. Mostre a URL, abra o navegador quando possível e consulte o backend até o resultado.

Evite interromper uma sessão crítica. Faça login em menu apropriado e mantenha rede e autenticação fora do loop principal.

O login inicial exige internet. O jogo pode definir um período offline próprio, considerando risco, expiração e tipo de conteúdo.

Sim. O cliente base usa somente a biblioteca padrão e pode funcionar em scripts, terminal, bots ou serviços.

Use o armazenamento seguro oferecido pelo sistema operacional ou um arquivo protegido, evitando texto puro quando o risco exigir proteção maior.

Sim. Adapte o polling à arquitetura assíncrona do projeto, sem bloquear o loop de eventos da interface ou do jogo.

A fila transfere resultados da thread de rede para a thread principal, onde a interface pode ser atualizada com segurança.

Sim. Gere o QR code a partir da login_url usando biblioteca confiável e mostre também a URL em texto.

Integre síntese de voz ou a camada de acessibilidade usada pelo jogo e anuncie mudanças de estado sem depender apenas da tela.

As bibliotecas padrão validam certificados por padrão. Não desative essa verificação para contornar erros de configuração.

Ele agenda atualizações na thread da interface, evitando manipular controles diretamente a partir da thread de rede.

Sim. O exemplo define botão padrão e foco adequado, mas o aplicativo final deve testar navegação completa por teclado.

Sim, mas a thread deve ser tratada com cuidado. Use sinal de cancelamento se o aplicativo mantiver recursos além de threads daemon.

Atualize um texto de estado ou indicador indeterminado pela thread principal enquanto o backend estiver pendente.

Sim. O exemplo separa protocolo e interface justamente para permitir reutilização e testes independentes.

Em geral sim, respeitando instalação, navegador padrão e armazenamento seguro disponível em cada plataforma.

Anexe-o a um GameObject persistente ou a um serviço de autenticação controlado pelo ciclo de vida do jogo.

Use um objeto persistente, serviço global ou armazenamento seguro e não dependa apenas de campos da cena atual.

Sim quando a plataforma está configurada normalmente. Não instale validadores que aceitem qualquer certificado.

Guarde uma referência, interrompa-a ao sair da tela e informe ao backend ou deixe a tentativa curta expirar.

Adicione o script a um Node, conecte os sinais e troque BACKEND_URL pela rota publicada.

Não para este fluxo. HTTPRequest, OS.shell_open, sinais e o backend seguro são suficientes.

Use solução segura adequada à plataforma e evite publicar o token em arquivos de configuração do projeto.

Sim, desde que o esquema ou link universal seja controlado e o callback continue protegido por state e PKCE.

Links universais verificados reduzem sequestro por outros aplicativos. Esquemas personalizados exigem cuidados adicionais.

Use uma página de ativação no celular ou computador, vinculada a um código curto e temporário mostrado pelo console.

Ele deve ser aleatório, curto apenas o suficiente para uso humano, expirar rapidamente e ser limitado contra tentativas.

Não. Mesmo ofuscado, o segredo pode ser extraído. Mantenha-o em infraestrutura controlada.

Use deep link verificado ou polling seguro contra o backend, conforme as capacidades da plataforma.

Sim, se a tentativa for vinculada por código ou QR e o backend entregar a sessão somente ao dispositivo que iniciou.

Faça uma etapa autenticada de vinculação, confirme a conta local e salve o id do Clube AGB sem criar duplicidade.

Procure primeiro pelo id do Clube AGB já salvo e ofereça vinculação segura para usuários locais existentes.

Sim. Os endpoints principais possuem limites para reduzir abuso e excesso de chamadas.

A API responde com status 429 e uma mensagem segura. A integração deve aguardar antes de tentar novamente.

Não. Erros temporários pedem espera progressiva; erros de credencial, retorno ou permissão exigem correção da configuração.

Não. Códigos, tokens, verificadores PKCE, segredos e sessões não devem aparecer em logs.

Registre evento, horário e categoria do problema, removendo credenciais, tokens, e-mails e detalhes internos desnecessários.

É uma regra do navegador que controla quais origens podem chamar um backend web. Jogos web devem usar uma lista explícita de origens permitidas.

Não em rotas autenticadas. Permita somente os domínios conhecidos do jogo ou aplicativo.

Sim. O exemplo inclui limites persistentes por ação, endereço e identificador da solicitação.

O exemplo usa PDO SQLite, JSON, hash e funções criptográficas padrão. Confirme a disponibilidade no servidor.

Sim. Preserve transações, índices, expiração, hashes e consumo único ao adaptar o esquema.

Use os recursos de configuração do domínio ou aplicação oferecidos pela hospedagem. Evite colocar segredos em arquivos públicos.

Sim. Ele precisa alcançar os endpoints de token e userinfo e possuir certificados confiáveis atualizados.

Confie em cabeçalhos de origem somente quando o proxy estiver explicitamente autorizado; caso contrário use REMOTE_ADDR.

Em ambientes profissionais, sim. Cofres de segredo facilitam rotação, auditoria e acesso mínimo.

Separe dados permanentes de tokens e solicitações temporárias ou exclua esses registros sensíveis do backup.

Sim. Expiração de códigos, tokens e limites depende de horário correto. Use sincronização confiável de tempo.

A solicitação está incompleta ou inválida, como parâmetros ausentes, state incorreto ou PKCE malformado.

A credencial, o código, o token, o verificador ou a sessão não foi aceito.

A operação foi entendida, mas não é permitida, como URL não autorizada, escopo proibido ou acesso negado.

O limite de requisições foi excedido. Aguarde e reduza a frequência das tentativas.

Houve falha interna ou na comunicação entre serviços. Não mostre detalhes técnicos ao usuário e registre diagnóstico seguro.

A redirect_uri enviada não corresponde exatamente a uma URL ativa cadastrada para o cliente.

O verificador foi perdido, alterado, reutilizado ou não corresponde ao challenge usado no início do fluxo.

Consulte logs privados do servidor, use identificadores de evento e reproduza o problema em ambiente de teste controlado.

HTTPS, variáveis privadas, PKCE obrigatório, URLs exatas, escopos mínimos, limites, logs e cenários de falha.

Use migração compatível, atualize clientes, monitore erros e só depois torne novas exigências obrigatórias.

Sim. Monitore disponibilidade, latência, erros, banco, espaço, limites e idade dos backups sem registrar segredos.

Revise após mudanças importantes, incidentes, novas integrações e atualizações relevantes de padrões ou dependências.

Para uso amplo ou dados relevantes, uma avaliação independente complementa testes internos e revisão de código.

Somente o proprietário autorizado ou administrador com permissão adequada no painel.

A política deve ser verificada no painel. Para incidente, revogue também tokens e sessões relacionados.

Use a ação de desativação no painel e reative somente depois de corrigir configuração ou incidente.

As ações relevantes da API são registradas para investigação e acompanhamento sem armazenar os segredos em texto puro.

Fora da pasta pública, em caminho privado gravável apenas pelo processo do servidor.

Sim. MySQL, PostgreSQL ou Redis podem substituir o SQLite mantendo expiração, atomicidade e proteção dos segredos.

Solicitações expiradas, sessões vencidas e janelas antigas de limite devem ser removidas para evitar crescimento desnecessário.

O projeto pode mostrar um QR code ou código de dispositivo que leve a uma página segura do backend para concluir a autorização.

Não. Abrir o navegador padrão do sistema é geralmente mais seguro e permite usar a sessão normal do Clube AGB.

A interface do Clube e os exemplos priorizam HTML semântico, foco e textos claros, mas cada projeto parceiro também deve testar sua acessibilidade.

Sim. O cliente pode reproduzir mensagens ou usar síntese de voz para informar navegador aberto, aguardando, sucesso, recusa ou erro.

Execute as consultas de rede em tarefa, coroutine ou thread apropriada ao motor, como mostram os exemplos fornecidos.

A integração deve mostrar uma mensagem clara, preservar o restante do jogo quando possível e permitir nova tentativa mais tarde.

O projeto deve usar credenciais e URL de retorno próprias para testes controlados antes da publicação definitiva.

Teste sucesso, recusa, state incorreto, PKCE incorreto, código repetido, expiração, falta de rede e revogação.

Confira o domínio oficial no navegador. Uma integração legítima não pede a senha do Clube dentro do site ou jogo parceiro.

O parceiro controla sua própria interface, mas a tela de autorização do Clube mantém identidade e informações de segurança oficiais.

Na área de SDK da Conexão Clube AGB, com guias universais, PHP, Python, Node, jogos e cópias públicas para leitura.

Sim. Elementos details e summary são nativos e podem ser acionados pelo teclado em navegadores modernos.

Sim. O campo possui rótulo e a quantidade de resultados é anunciada por uma região de status.

Não devem depender. Títulos, textos, estados e controles precisam continuar compreensíveis sem percepção de cor.

Informe página, tecnologia assistiva, navegador, passos e resultado esperado para facilitar reprodução e correção.

É o módulo que permite a sites parceiros vincular uma conta local à identidade autorizada do Clube AGB, sem compartilhar a senha do usuário.

A administração do Clube AGB cadastra o site e entrega um client_id e um client_secret. O segredo deve ficar somente no backend do parceiro.

O usuário entra no Clube AGB, gera um código temporário e informa esse código no site parceiro. O backend do parceiro confirma o código pela API.

Não. O parceiro recebe apenas o resultado autorizado do vínculo e um account_key opaco para reconhecer a conta vinculada.

Consulte o Guia de integração para sites parceiros, que descreve o fluxo, os endpoints, os campos e os erros.