Proteja cada aplicação sem abdicar do controlo

Ajuda-me a adicionar suporte OpenID Connect com FoxIDs à minha aplicação.

Restrições de âmbito:
- Podes usar o nome da pasta do workspace como contexto.
- Não leias, procures, abras, inspeciones nem infiras nada fora da pasta atual do workspace.
- Se esta for uma nova aplicação, não percas tempo a procurar no workspace uma implementação existente. Cria ou gera o necessário dentro da pasta atual do workspace e depois integra FoxIDs.
- Se esta for uma aplicação existente, inspeciona apenas ficheiros dentro da pasta atual do workspace.

Antes de escrever qualquer código, faz as perguntas necessárias em exatamente duas fases.

Perguntas da fase 1:
Faz perguntas concisas para determinar:
- tipo de aplicação
- linguagem
- framework e versão
- modelo de hosting
- se a auth é client-side, server-side ou não se sabe
- se esta é uma nova aplicação ou uma aplicação existente

Perguntas da fase 2:
- Faz estas perguntas apenas se for uma aplicação existente.
- Faz perguntas concisas sobre:
  - o método atual de autenticação
  - onde estão configuradas as atuais definições de autenticação
  - se já existe alguma UI de login/logout
  - se já existe uma home page ou layout onde devam ser adicionadas alterações mínimas de auth UI

Regras de execução:
- Não inicies alterações de código antes de ambas as fases de perguntas estarem concluídas, ou antes de a fase 1 estar concluída e estar confirmado que se trata de uma nova aplicação.
- Se for uma nova aplicação, avança diretamente para a implementação após a fase 1. Não realizes pesquisas exploratórias cujo único objetivo seja descobrir se já existem ficheiros.
- Se for uma aplicação existente, inspeciona apenas o mínimo necessário antes de fazer alterações.
- Não faças perguntas de seguimento desnecessárias se as respostas anteriores forem suficientes para implementar corretamente a integração.

Requisitos de implementação:
- Adiciona definições para:
  - `Authority`
  - `ClientId`
- Se a aplicação for server-based:
  - adiciona `ClientSecret`
  - usa uma session cookie
  - mantém os tokens no servidor
  - PKCE é opcional
- Se a aplicação não for server-based:
  - não uses `ClientSecret`
  - usa authorization code flow com PKCE
- Define o response type como `code`
- Define os scopes para incluir:
  - `openid`
  - `profile`
  - `email`
- Se for suportado, define:
  - Name claim type para `sub`
  - Role claim type para `role`
- Usa JWT claims na aplicação
- Dá preferência ao uso de OpenID Connect Discovery e da informação descarregada, incluindo chaves.
- Dá preferência à validação de JWT tokens usando OpenID Connect Discovery e chaves descarregadas e à leitura dos claims a partir do JWT token validado
- Apenas se OpenID Connect Discovery e a validação de JWT tokens não forem suportadas, usa:
  - user info endpoint: `Authority` + `/oauth/userinfo`
  - authorize endpoint: `Authority` + `/oauth/authorize`
  - token endpoint: `Authority` + `/oauth/token`
- Implementa login e log off
- Adiciona botões de Log in e Log off
- Depois do login, mostra os claims para debugging e indica claramente que a visualização dos debug claims deve ser removida mais tarde
- Garante que os dados só são obtidos e mostrados quando o utilizador está autenticado
- Garante que os dados protegidos não são mostrados a utilizadores anónimos
- Se existirem APIs, protege-as com o modelo de auth da aplicação:
  - para aplicações server-based, protege as APIs com a session cookie, a menos que a arquitetura exija especificamente access tokens
  - para aplicações não server-based, protege as APIs com um access token
- Se existirem chamadas autenticadas a APIs ou carregamentos de dados a partir da UI, garante que só são executados para utilizadores autenticados

Guardrails para uma aplicação existente:
- Não introduzas refatoração não relacionada
- Não removas funcionalidades existentes, a menos que isso seja estritamente necessário para a integração OIDC do FoxIDs
- Mantém as alterações na home page ou no layout mínimas
- Adiciona apenas o necessário para:
  - Log in
  - Log off
  - visualização temporária de debug claims
  - controlo da apresentação de dados autenticados e de fetches protegidos
  - proteção de APIs, se existirem

Output obrigatório após a implementação:
Fornece sempre tudo o seguinte:
- O domínio de redirect ou a redirect URI exatos a configurar no FoxIDs
- Exatamente onde as definições estão configuradas
- Se for uma aplicação existente, a lista de ficheiros alterados
- quaisquer passos manuais ainda necessários, pela ordem exata em que o utilizador os deve executar no FoxIDs e na aplicação
- Uma breve explicação de como adicionar e configurar a aplicação no FoxIDs como OpenID Connect web application

Nível de qualidade:
- Dá preferência à abordagem de autenticação nativa do framework para o tipo de aplicação detetado
- Mantém a implementação mínima e sensata para produção
- Não acrescentes código placeholder se uma integração real puder ser implementada
- Se algo não puder ser concluído com o workspace ou o tooling disponíveis, indica exatamente o que está bloqueado e fornece o menor passo seguinte viável