Token refresh w OAuth2: jak nie wpaść w cichą wygasłą sesję
Integracja chodziła tygodniami jak złoto, aż pewnej nocy token wygasł i wszystko zamilkło. Żadnego błędu, żadnego alertu, po prostu cisza. Najgorszy rodzaj awarii to ten, którego nie widać. Pokazuję, jak odświeżam tokeny OAuth2, żeby się o tym nie dowiadywać od klienta.
Najgorsza awaria to ta, której nie widać
Wygasły token nie wywala workflow z hukiem. On po prostu sprawia, że krok zwraca 401 albo pustkę, a reszta przepływu leci dalej, jakby nic się nie stało. Nie ma czerwonego wykrzyknika, nie ma maila z alertem. Jest cisza. I ta cisza trwa, aż klient napisze, że od trzech dni nic nie przychodzi.
Pracowałem z integracjami marketplace i płatności, gdzie token bywał najczęstszym pojedynczym punktem awarii. Nie sama integracja, nie logika biznesowa. Token. Dlatego traktuję go dziś jak element krytyczny, a nie jak szczegół konfiguracji.
Trzy rzeczy, które robię z każdym tokenem
1. Odświeżam zanim wygaśnie, nie po błędzie. Zapisuję czas ważności access tokenu i odświeżam go z zapasem, na przykład kilka minut przed końcem. Czekanie na pierwsze 401, żeby dopiero wtedy zareagować, oznacza, że co najmniej jedno wywołanie już padło. Lepiej zapobiegać niż łatać.
2. Trzymam refresh token zaszyfrowany i w jednym miejscu. Nigdy w kodzie, nigdy w commitowanym pliku. Sekret siedzi w menedżerze sekretów, a workflow czyta go w locie. Po odświeżeniu nowy access token ląduje w jednym wspólnym miejscu, z którego korzystają wszystkie procesy. Dzięki temu nie mam pięciu kopii tokenu, które rozjeżdżają się w czasie.
3. Wykrywam cichą awarię i głośno o niej mówię. Brak danych to też sygnał. Jeśli krok, który zawsze coś zwraca, nagle zwraca pustkę albo 401, traktuję to jak twardy błąd, a nie jak naturalny pusty wynik. Wtedy leci alert, a nie cisza.
Token to nie szczegół konfiguracji. To najczęstszy pojedynczy powód, dla którego dobra integracja przestaje działać po cichu.
Schemat odświeżania w praktyce
W n8n układam to zwykle tak:
- Przed wywołaniem API sprawdzam, czy access token jeszcze żyje, na podstawie zapisanego czasu ważności.
- Jeśli zostało mało czasu, najpierw odświeżam token przez refresh token, dopiero potem wołam właściwe API.
- Nowy access token i nowy czas ważności zapisuję w jednym miejscu.
- Jeśli odświeżanie samo zwróci błąd, to jest sytuacja alarmowa, bo oznacza, że refresh token też mógł stracić ważność albo dostęp został cofnięty.
Sprawdź, zanim Cię zaskoczy
Jeśli masz integrację, która chodzi po OAuth2 i sama trzyma kciuki, że token nie wygaśnie, to nie jest stabilność, tylko szczęście. Dorzuć proaktywne odświeżanie, jedno miejsce na token i wykrywanie pustych odpowiedzi. To kilka godzin pracy, które oszczędzają telefon od klienta o ósmej rano z pytaniem, czemu nic nie działa.
Najczęstsze pytania
Dlaczego integracja OAuth2 przestaje działać bez żadnego błędu?
Bo wygasły access token zwykle kończy się odpowiedzią 401 albo pustym wynikiem, a wiele workflow nie traktuje tego jako twardego błędu. Krok po prostu nic nie zwraca, kolejne lecą dalej, a Ty nie dostajesz żadnego sygnału. To klasyczna cicha awaria: nic się nie wywala, tylko nic się nie dzieje.
Jak bezpiecznie przechowywać i odświeżać refresh token?
Refresh token trzymam zaszyfrowany, poza kodem i poza repozytorium, najlepiej w menedżerze sekretów. Access token odświeżam zanim wygaśnie, na podstawie czasu ważności, a nie dopiero po błędzie 401. Każde odświeżenie zapisuje nowy token w jednym miejscu, z którego korzystają wszystkie workflow, żeby nie rozjechały się wersje.
Masz integrację, która lubi cicho umierać?
U Ciebie zaczynam od warsztatu procesu (90 minut, bezpłatny). Przejdziemy przez Twoje integracje i pokażę, gdzie brakuje wykrywania awarii. Bez wciskania jednego słusznego stacku.
Zamów warsztat → Lub napisz bezpośrednio.