# SSO SUPER GCH

## Contrato preparado
A implementação usa Authorization Code + PKCE S256.

1. `/sso/login` cria `state`, `nonce` e `code_verifier`.
2. O browser é redireccionado para o authorization endpoint do GCH.
3. `/sso/callback` valida `state`.
4. O código é trocado no token endpoint com `code_verifier`.
5. O `id_token` é validado localmente: RS256, assinatura, `iss`, `aud`, `exp`, `iat` e `nonce`.
6. Só os claims explicitamente mapeados em `config/sso.php` são persistidos.
7. O estado de acesso deve estar num valor institucional activo.
8. Os papéis comerciais NÃO são importados do GCH.

## Claims mínimos
`sub`, nome, nome preferido, e-mail profissional, telefone profissional quando autorizado, employee/person id, cargo, unidade orgânica e estado de acesso.

Não persistir salário, assiduidade, disciplina, saúde, documentos pessoais, benefícios ou outros dados de Capital Humano.

## Backchannel logout
`POST /api/v1/sso/backchannel-logout`

Cabeçalhos: `X-SUPER-Timestamp`, `X-SUPER-Nonce`, `X-SUPER-Signature`.

Canonical string: `timestamp + "\n" + nonce + "\n" + sha256(raw_body)`.

Body mínimo: `{"sub":"..."}`.

A aplicação revoga todas as sessões activas desse `sub`. O nonce é persistido com UNIQUE para bloquear replay.

## Dependências do contrato real do GCH
Os endpoints exactos, client ID/secret, nomes exactos dos claims e chave pública devem ser preenchidos com os dados reais do IdP. Não foram inventados neste pacote.