MCP: prihlaseni jmenem a heslem, tokeny si obstarava portal

Predchozi verze chtela po uzivateli token. Spatne zadani: zakaznik dostane ke
svemu serveru adresu, jmeno a heslo. Token nedostane a nema jak ho ziskat -
vyda ho az autorizacni server a ma omezenou zivotnost. Obstarat ho, hlidat
platnost a vcas ho obnovit je prace portalu.

Novy src/mcp/auth.ts:
- kde se prihlasit se zjisti od serveru pres
  /.well-known/oauth-protected-resource a metadata autorizacniho serveru.
  Rucni pole na adresu je jen zaloha pro servery, ktere metadata nemaji
- cim se zkusi v poradi client_credentials a password. Ktere z toho firma
  dostala, se z udaju samych poznat neda a nutit ji to vybirat by znamenalo
  ptat se na neco, co nevi
- bez autorizacniho serveru se posle HTTP Basic. Mensi servery zadny OAuth
  nemaji a jmeno s heslem je u nich presne tohle
- zivotnost urcuje server: token se vymeni minutu pred vyprsenim, obnovi se
  pres refresh_token, kdyz ho server vydal, a kdyz expires_in chybi, pocita se
  s peti minutami, tedy odhaduje se dolu
- odmitnuty token (401 na token, ktery jsme meli za platny) se zahodi a volani
  se zopakuje jednou. Podruhe uz ne, to uz nejsou platne udaje

Token se drzi jen v pameti. Je kratkodoby, po restartu se o novy rekne znovu,
a ulozit ho by znamenalo vsechna rizika ulozeni bez jakekoliv vyhody. Kes drzi
otisk udaju, takze zmena hesla ulozeny token zneplatni.

Udaje konektoru jsou ted adresa, jmeno, heslo a dve nepovinna pole (adresa pro
prihlaseni a rozsah opravneni). Ani jedno nemiri do hlavicky - Authorization se
pocita az pri volani z toho, co vydal autorizacni server.

Zpusob prihlaseni se pise do hlasky u konektoru: uzivatel vyplnil jmeno a heslo
a ma vedet, jak s nimi portal nalozil, nez zacne hledat chybu jinde.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

documentation/99-zmeny.md

@@ -2,6 +2,35 @@
 
 Nejnovejsi nahore.
 
+## 2026-08-28 - MCP: prihlaseni jmenem a heslem, tokeny si resi portal
+
+Predchozi verze chtela po uzivateli token. To bylo spatne zadani: zakaznik
+dostane ke svemu serveru **adresu, jmeno a heslo**, token nedostane a nema jak
+ho ziskat - vyda ho az autorizacni server a ma omezenou zivotnost.
+
+Novy `src/mcp/auth.ts` resi cely zivotni cyklus:
+
+- **Kde se prihlasit** se zjisti od serveru pres
+  `/.well-known/oauth-protected-resource` a metadata autorizacniho serveru.
+  Rucni pole na adresu je jen zaloha pro servery, ktere metadata nemaji.
+- **Cim** se zkusi v poradi `client_credentials` a `password`. Ktere z toho
+  firma dostala, se z udaju samych poznat neda a nutit ji to vybirat by
+  znamenalo ptat se na neco, co nevi.
+- **Bez autorizacniho serveru** se posle HTTP Basic. Mensi servery zadny OAuth
+  nemaji a jmeno s heslem je u nich presne tohle.
+- **Zivotnost urcuje server.** Token se vymeni minutu pred vyprsenim, obnovi se
+  pres `refresh_token`, kdyz ho server vydal, a kdyz `expires_in` chybi, pocita
+  se s peti minutami - tedy odhaduje se dolu.
+- **Odmitnuty token** (401 na token, ktery jsme meli za platny) se zahodi
+  a volani se zopakuje jednou. Podruhe uz ne, to uz nejsou platne udaje.
+
+Token se drzi **jen v pameti**. Je kratkodoby, po restartu se o novy rekne
+znovu, a ulozit ho by znamenalo vsechna rizika ulozeni bez jakekoliv vyhody.
+Kes si drzi otisk udaju, takze zmena hesla ulozeny token zneplatni.
+
+Zpusob prihlaseni je videt v hlasce u konektoru: uzivatel vyplnil jmeno a heslo
+a ma vedet, jak s nimi portal nalozil, nez zacne hledat chybu jinde.
+
 ## 2026-08-28 - MCP konektory hotove
 
 Firma si zalozi napojeni na svuj MCP server, stiskne **Nacist nastroje** a jeho