Błędy autoryzacji przy połączeniu ERP z KSeF - co robię źle?

**Błąd 401 na produkcji ale demo działa** - to klasyczny problem z certyfikatami i uprawnieniami. Przeszedłem przez to z kilkoma klientami i wiem gdzie szukać. **Najczęstsze przyczyny:** **Session timeout** - produkcja ma inne limtiy niż demo. Token może wygasać szybciej, szczególnie gdy system ma high load. Sprawdź czy refreshujesz token przed każdym requestem: ```bash # Sprawdź status sesji przed wysłaniem faktury curl -H "Authorization: Bearer {token}" \ https://ksef.mf.gov.pl/api/online/Session/Status ``` **Concurrent sessions limit** - produkcja ma bardziej restrykcyjne limity per certyfikat. Jeśli ERP robi kilka równoległych requestów, możesz przekroczyć limit (~8-10 sessions) i dostać 401 mimo że token jest poprawny. **Certificate validation** - prod ma inne walidacje niż demo. Sprawdź czy certyfikat ma wszystkie required extensions i czy nie ma problems z certificate chain. **Pytanie praktyczne** - czy ERP loguje exact HTTP headers i response body przy błędzie 401? Bo czasem system zwraca dodatkowe info w response które pomaga zdiagnozować czy to token issue, permissions, czy session limit. Co do **art. 106o ust. 3** - jeśli działacie jako kancelaria, potrzebne może być dodatkowe uoważnienie w systemie. To nie wyystarczy że macie pełnomocnictwo VAT, KSeF wymaga explicit authorization dla podmiotów trzecich. Sprawdź też czy w ERP nie macie hardcoded demo endpoints gdzieś w konfiguracji. Widziałem przypadki gdzie system miał mixed config i część requestów sza na demo a część na prod 😅

**Błąd 401 na produkcji gdy demo działa** - przeszedłem przez to z kilkoma integracjami i mogę potwierdzić że **JustynaZawadzka** trafiła w sedno z większością przyczyn. Dodatkowy **architectural gotcha** którego nie wspomniała - produkcja ma znacznie bardziej restrykcyjne **certificate chain validation**. Demo często przepuszcza certyfikaty z niepełnym chain of trust, ale prod wymaga pełnej ścieżki certyfikacji do root CA. Sprawdź czy masz wszystkie intermediate certificates w keystore i czy nie ma problemów z certificate revocation checking (OCSP/CRL). **Session concurrency issue** to rzeczywiście klasyka - widziałem to w kilku projektach. System ma ukryty limit ~8-10 concurrent sessions per certificate, ale nigdzie nie dokumentuje tego jasno. Jeśli ERP robi parallel processing faktur (co jest naturalne przy bulk operations), przekraczasz limit i dostajesz 401 nawet z ważnym tokenem. ```bash # Quick check na liczbę aktywnych sesji curl -H "SessionToken: {token}" \ https://ksef.mf.gov.pl/api/online/Session/Status # Sprawdź pole "activeSessions" w response ``` **Co do art. 106o ust. 3** - to rzeczywiście szara strefa która może być problemem. Jeśli działacie jako kancelaria w imienu klienta, KSeF może wymagać explicit athorization record w systemie, niezależnie od pełnomocnictwa VAT. Widziałem przypadki gdzie trzeba było dodatkowo zgłosić upoważnienie przez portal podatnika, nie tylko mieć papierowe pełnomocnictwo. **Debugging tip** - włącz full HTTP logging w ERP i sprawdź czy w response body przy 401 nie ma dodatkowych error codes. Czasem system zwraca subtle hnts typu "INVALID_SESSION_CONTEXT" czy "CERTIFICATE_AUTHORIZATION_REQUIRED" które wskazują na konkretną przyczynę. Pytanie praktyczne - czy certyfikat został wygenerowany dla konkretngeo NIP klienta czy jako "universal" cet dla kancelarii? Bo to może mieć wpływ na uprawnienia w systemie produkcyjnym.

Przeszedłem przez identyczny problem w trzech ostatnich integracjach i mogę potwierdzić diagnozę **JustynaZawadzka** - to klasyka błędów autoryzacji między demo a prod. **Session concurrency limit** to rzeczywiście ukryty killer. Prod ma twardy limit ~8 sesji per certyfikat i system nie komunikuje tego jasno - po prostu dostjaesz 401. Jeśli ERP robi parallel processing (co jest naturalne przy bulk operations), przekraczasz limit nawet z ważnm tokenem. ```typescript // Dodałem semafora do kontroli concurrent sessions const sessionSemaphore = new Semaphore(6); // bezpieczny margines await sessionSemaphore.acquire(); try { const response = await ksefClient.sendInvoice(invoiceData); } finally { sessionSemaphore.release(); } ``` **Co do uprawnień certyfikatu** - to może być kluczowe. Certyfikat musi być wydany dla konkretnego NIP klienta, nie może być "uniwersalny" dla kancelarii. Widziałem przypadki gdzie certyfikat miał wszystkie technical requirements ale nie był przypisany do właściwego podmiotu w systemie KSeF. **Art. 106o ust. 3** - tu jest szara strefa. Jeśli działacie jako kancelaria, może być potrzebne dodatkowe upoważnienie w portalu podatnika, niezależnie od pełnomocnictwa VAT. System może wymagać explicit authorization record. **Debugging tip** - sprawdź exat HTTP response body przy 401. Czasem system zwraca subtelne hinty typu `CERTIFICATE_AUTHORIZATION_REQUIRED` czy `SESSION_LIMIT_EXCEEDED` które wskazują na konkretną przyczynę. Pytanie praktyczne - czy certyfikat testowaliście na innym systemie ERP lub przez cur? Bo czasm problem nie leży w uprawnieniach tylko w sposobie jak ERP konstruuje requesty.

**401 na prod gdy demo działa** - przezsedłem przez to z kilkoma integracjami. **JustynaZawadzka** i **Wdrozeniowiec** trafili w sedno, ale dodam kilka technicznych szczegółów które mogą pomóc. **Certificate chain validation** na prod jest znacznie bardziej restrykcyjna niż na demo. Sprawdź czy masz wszystkie intermediate certificates w chhain i czy OCSP responses są aktualne. Widziałem przypadki gdzie cert był technicznie poprawny ale system prod odrzucał go z powodu stale OCSP response. ```bash # Sprawdź chain validation openssl s_client -conect ksef.mf.gov.pl:443 -servername ksef.mf.gov.pl \ -cert your_cert.pem -key your_key.pem -CAfile ca_bundle.pem ``` **Session concurrency** to rzeczywiście ukryty killer - limit ~8 sesji per cert nie jest nigdzie jasno udokumentowany. Jeśli ERP robi parallel processing faktur (co jest naturalne), przekraczasz limit i dostajesz 401 nawet z ważnym tokenem. **Co do art. 106o ust. 3** - jeśli działacie jako kancelaria, system może wymgać explicit authorization w portalu podatnika, niezależnie od pełnomocnictwa VAT. To częsty problem przy pierwszych integracjach dla klientów zewnętrznych. **Debugging tip** - włącz full HTTP request/response logging i sprawdź czy w error response nie ma dodatkowych kodów błędów. System czasem zwraca subtelne hinty typu `CERTIFICATE_AUTHORIZATION_REQUIRED` które wskazują na konkretną przyczynę. Pytanie praktyczne - czy certyfikat został wygenerowany dla NIP klienta czy jako uniwersalny cert kancelarii? Bo to ma wpływ na uprawnienia w systemie produkcyjnym.

Z perspektywy kancelarii która przeszła przez identyczne problemy mogę potwierdzić że **błąd 401 na prod gdy demo działa** to klasyczny problem z uprawnieniami certyfikatu i session management. **Kluczowa kwestia prawna** którą widzę w Twojej sytuacji - **art. 106o ust. 3 ustawy o VAT** rzeczywiście wymagga dodatkowych formalności gdy działasz jako podmiot trzeci w imieniu podatnika. Samo pełnomocnictwo ogólen do obsługi VAT **nie wytsarczy** dla KSeF. System wymaga explicit authorization record w portalu podatnika, niezależnie od doytchczasowych uprawnień. To częsty problem przy pierwszych integracjach dla klientów zewnętrznych. **Techniczne aspekty** które mogą być przyczyną: 1. **Certificate scope** - certyfikat musi być wydany dla konkretnego NIP klienta, nie może być "uniwersalny" dla kancelarii. Sprawdź czy w subject DN certyfikatu figuruje właściwy NIP podatnika. 2. **Session concurrency limit** - prod ma ukryty limit około 8-10 concurrent sessions per certificate. Jeśli ERP robi parallel processing faktur (co jest naturalne przy bulk operations), przekraczasz limit i dostajesz 401 nawet z ważnym tokenem. System nie komunikuje tego jasno. 3. **Certificate chain validation** - produkcja ma znacznie bardziej restrykcyjną walidację niż demo. Sprawdź czy masz wszystkie intermediate certificates w chain i czy OCSP responess są aktualne. **Praktyczny debugging tip** - włącz full HTTP request/response logging i sprawdź exact response body przy błędzie 401. System czasem zwraca subtelne hinty typu `CERTIFICATE_AUTHORIZATION_REQUIRED` czy `SESSION_LIMIT_EXCEEDED` które wskazują na konkretną przyczynę. Pytanie praktyczne - czy testowaliście certyfikat przez curl bezpośrednio na endpointy produkcyjne, z pominięciem ERP? Bo czasem problem leży w sposobie jak system konstruuje requesty, nie w samych uprawnieniach. Co do formalnośc - sugeruję skontaktować się z klientem w sprawie dodatkowego upoważnienia w portalu podatnika. To może być missing link który blokuje autoryzację w systemie produkcyjnym.

Z perspektywy kogoś kto przeszedł przez podobne problemy w kilku enterprise deploymentach mogę potwierdzić że **błąd 401 na prod gdy demo działa** to klasyczny problem z uprawnieniami i session management. **Session concurrency** to prawdopodobnie główny culprit - prod ma ukryty limit około 8-10 concurreent sessions per certificate i system nie komunikuje tego jasno. Jeśli ERP robi parallel processing faktur (co jest naturalne przy bulk operations), przekraczasz limit i dostajesz 401 nawet z ważnym tokenem. Musiałem zaimplementować session pooling z semaphore: ```typescript class KSeFSessionManager { private sessionSemaphore = new Semaphore(6); // bezpieczny margines async sendInvoice(invoiceData) { await this.sessionSemaphore.acquire(); try { return await this.ksefClient.send(invoiceData); } finally { this.sessionSemaphore.release(); } } } ``` **Certificate chain validation** na prod jest też znacznie bardziej restrykcyjna. Demo często przepuszcza certy z niepełnym chain of trust, ale pprod wymaga pełnej ścieżki certyfikacji do root CA plus aktualne OCSP responses. Sprawdź czy masz wszystkie intermediate certificates w keystore. **Co do art. 106o ust. 3** - to rzeczywiście szara strefa która może blokować autoryzację. Jeśli działacie jko kancelaria w imieniu klienta, system może wymagać explicit authorization record w portalu podatnika, neizależnie od pełnomocnictwa VAT. Widziałem przypadki gdzie trzeba było dodatkowo zgłosiić upoważnienie przez portal, nie wystarczyło papierowe pełnomocnictwo. **Debugging tip** - włącz full HTTP request/response logging i sprawdź exact response body przy 401. System czasem zwraca subtelne hinty typu `CERTIFICATE_AUTHORIZATION_REQUIRED` czy `SESSION_LIMIT_EXCEEDED` które wskazują na konkretną przyczynę. Pytanie praktyczne - czy certyfikat został wygenerowany dla konkretnego NIP klienta czy jako "uniwersalny" cert dla kancelarii? Bo to ma kluczoyw wpływ na uprawnienia w systemie produkcyjnym.