OAuth ryšys nustojo veikti po kelių savaičių: kaip rasti ir sutvarkyti nebegaliojantį tokeną

OAuth ryšys nustojo veikti po kelių savaičių, nors viskas veikė be klaidų. Niekas nekeitė workflow, niekas nekeitė prisijungimo duomenų, o šiandien ryte Google mazgas grąžina 401, nors veikė be priekaištų nuo pavasario. Tai dažniausia priežastis, dėl kurios į mus kreipiamasi, ir ji beveik niekada nėra Jūsų automatizacijos logikoje: kažkieno paskyrai išduotas tokenas baigė galioti arba buvo atšauktas visai kitoje vietoje, o dauguma platformų apie tai praneša tik tada, kai kitas vykdymas nepavyksta.

Žemiau rasite keturis šio gedimo variantus su žurnalų ištraukomis, lentelę, kiek iš tikrųjų galioja tokenai pas dažniausiai jungiamus tiekėjus, ir pagal grafiką veikiantį workflow, kurį galite importuoti šiandien. Tada apie kitą nebegaliojantį tokeną sužinosite iš savo pranešimo, o ne iš kliento skundo.

OAuth nustojo veikti po kelių savaičių: keturi to paties gedimo variantai

Atnaujinimo užklausa grąžina invalid_grant

Kiekviena OAuth integracija turi du tokenus. Trumpai galiojantis prieigos tokenas (access token) pridedamas prie kiekvienos užklausos, o atnaujinimo tokenas (refresh token) naudojamas fone, kad būtų gautas naujas prieigos tokenas, kai senasis nustoja galioti. Kai nebegalioja pats atnaujinimo tokenas, klaida atsiranda tokenų išdavimo taške (token endpoint). Todėl klaidos tekste kalbama apie leidimą (grant), o ne apie Jūsų paskyrą.

POST https://oauth2.googleapis.com/token
HTTP/1.1 400 Bad Request

{
  "error": "invalid_grant",
  "error_description": "Token has been expired or revoked."
}

Automatizavimo platforma šią klaidą paverčia bendresniu ir gerokai mažiau naudingu pranešimu. n8n vykdymo žurnale tas pats įvykis atrodo taip, todėl „google credentials expired n8n“ ir yra tokia dažna paieškos frazė:

NodeApiError: Authorization failed - please check your credentials
  node:        "Google Sheets"
  httpCode:    "401"
  description: "Forbidden - perhaps check your credentials?"

Šis patarimas klaidina. Prisijungimo duomenys n8n nepažeisti, šalia vis dar rodomas paskyros el. paštas, ryšys atrodo prijungtas. Nustojo veikti tai, kas yra Google pusėje. Todėl pakanka iš naujo atidaryti prisijungimo duomenis ir dar kartą patvirtinti sutikimo langą (consent screen). Workflow taisyti nereikia.

403 su nepakankamų leidimų atsakymu

Ši klaida dažniausiai pasirodo po pakartotinio prijungimo, kai kas nors antrą kartą suteikė mažiau leidimų. Autentifikacija pavyksta, o operacija ne.

GET https://www.googleapis.com/drive/v3/files?q=...
HTTP/1.1 403 Forbidden

{
  "error": {
    "code": 403,
    "message": "Request had insufficient authentication scopes.",
    "status": "PERMISSION_DENIED",
    "errors": [
      { "domain": "global",
        "reason": "insufficientPermissions",
        "message": "Insufficient Permission" }
    ]
  }
}

Svarbus laukas reason. insufficientPermissions reiškia, kad tokenas galioja, tik neturi leidimų srities (scope), kurios reikia būtent šiai užklausai. Taip nutinka, kai kas nors skubėdamas Google sutikimo lange nuima varnelę, arba kai programos prašomų sričių sąrašas pasikeitė nuo pirmo prijungimo. Prijungus dar kartą ir nesutvarkius leidimų, gaunamas lygiai toks pat 403. Taip žmonės per vieną popietę penkis kartus prijungia tuos pačius prisijungimo duomenis ir nusprendžia, kad sugedo platforma.

Kažkas atšaukė prieigą, o automatizacija apie tai nesužinojo

Prieiga atšaukiama nebūtinai sąmoningai. Tą patį padaro slaptažodžio pakeitimas, darbuotojo išėjimas, administratorius, tvarkantis trečiųjų šalių programas, arba saugumo politika, suveikusi dėl rizikos signalo. Šis variantas klastingesnis, nes HTTP lygmeniu dažnai pranešama apie sėkmę.

POST https://slack.com/api/chat.postMessage
HTTP/1.1 200 OK

{ "ok": false, "error": "token_revoked" }

Pažiūrėkite į būsenos eilutę. Užklausa pavyko, apie klaidą pranešama tik atsakymo turinyje, o mazgas, kuris tikrina tik būsenos kodą, pažymės vykdymą kaip sėkmingą, nors niekas nebus išsiųsta. Tai vienas iš atvejų, kai workflow veikia, bet nieko nevyksta. Microsoft bent jau aiškiai įvardija tokį įvykį:

AADSTS50173: The provided grant has expired due to it being revoked,
a fresh auth token is needed. The user might have changed or reset
their password.

Viena iš kelių paskyrų nustoja veikti, o vykdymas vis tiek rodo sėkmę

Brangiausiai kainuoja dalinis gedimas. Workflow apdoroja keturias pašto dėžutes ar šešias reklamos paskyras, vienų prisijungimo duomenys nustoja galioti, ciklas nustatytas tęsti darbą po klaidos, o vykdymų sąrašas savaitėmis rodo sėkmę.

[08:14:02]  Send digest   ok    mailbox=ops@
[08:14:03]  Send digest   ok    mailbox=sales@
[08:14:04]  Send digest   401   mailbox=founder@   invalid_grant
[08:14:05]  Send digest   ok    mailbox=support@
[08:14:07]  Execution finished   status=success   items=3/4

Iš pirmo žvilgsnio 3/4 niekas nelaiko klaida. Viename mūsų vertintame taisymo projekte potencialių klientų paskirstymo workflow, vykdomas apie 200 kartų per dieną, maždaug kartą per dieną lūždavo būtent taip. Vienintelis jo įspėjimas keliaudavo į Slack kanalą, suarchyvuotą prieš kelis mėnesius. Užklausos buvo prarastos anksčiau, nei kas nors suprato, kad kažkas negerai. Jei automatizacija nustojo veikti ir įtariate prisijungimo duomenis, pirmiausia paklauskite: kiek pastarųjų vykdymų baigėsi sėkme, bet nieko nepristatė?

Tokenų galiojimas pas skirtingus tiekėjus

Šiais duomenimis remiamės kurdami stebėjimą. Kur galiojimą nustato programos savininkas ar administratoriaus politika, o ne pats tiekėjas, lentelėje taip ir parašyta, be išgalvotų skaičių.

Tiekėjas	Prieigos tokenas	Atnaujinimo arba ilgai galiojantis tokenas	Kas jį nutraukia anksčiau laiko
Google	Apie vieną valandą	Publikuotai programai pagal laiką nebaigia galioti	OAuth programa, kurios būsena vis dar Testing, išduoda atnaujinimo tokenus, kurie baigia galioti po 7 dienų. Taip pat: naudotojas atšaukia prieigą savo Google paskyroje, pakeičiamas slaptažodis, kai naudojamos jautrios leidimų sritys, ir tokenų skaičiaus riba vienam naudotojui ir klientui: išdavus naują tokeną, seniausi tyliai panaikinami.
Microsoft Entra ID	Maždaug valandą, tikslią reikšmę Microsoft parenka atsitiktinai	Priklauso nuo neaktyvumo laikotarpių ir sesijų politikos, o ne nuo galiojimo trukmės, kurią galėtumėte nustatyti; senosios konfigūruojamos trukmės politikos panaikintos	Slaptažodžio atstatymas (AADSTS50173), administratorius atšaukia sesijas, o Conditional Access su nuolatiniu prieigos vertinimu (continuous access evaluation) nutraukia dar galiojantį tokeną, kai pasikeičia rizika ar vieta.
Slack, su įjungta tokenų rotacija	12 valandų	Atnaujinimo tokenas vienkartinis; kiekvienas atnaujinimas grąžina naują, kuris pakeičia senąjį	Praleistas rotacijos ciklas, nes senasis atnaujinimo tokenas jau panaudotas. Programos, kurios saugo atnaujinimo tokeną ten, kur negali įrašyti naujo, čia sugenda visam laikui.
Meta (Facebook, Instagram)	Trumpai galiojantis naudotojo tokenas, apie valandą	Ilgai galiojantis naudotojo tokenas, apie 60 dienų	Naudotojas pakeičia Facebook slaptažodį, administratorius pašalina programą arba pasikeičia vaidmuo puslapyje (Page). Puslapio tokenai, gauti iš ilgai galiojančio naudotojo tokeno, elgiasi kitaip, o detalės priklauso nuo to, kaip programa jų paprašė.
HubSpot	30 minučių	Atnaujinimo tokenas pagal laiką nebaigia galioti	Programa pašalinama iš portalo arba administratorius atjungia integraciją.

Iš šios lentelės matyti du dalykai. Pirma, „token refresh failed“ vyksta fone, todėl kai žmogus pamato klaidą, prisijungimo duomenys paprastai jau kelias valandas neveikia. Antra, Google testavimo režimo spąstai, į kuriuos jau patekome trijose skirtingose klientų sistemose: kūrėjas nepakeitė OAuth sutikimo lango būsenos iš Testing į Published, savaitę viskas veikė, o aštuntą dieną sugedo. Jei Jūsų integracija lūžta įtartinai reguliariai, pirmiausia patikrinkite programos publikavimo būseną.

Stebėjimas, kad tai netaptų netikėtumu

Tokeno galiojimo pabaigą galima numatyti, ko negalima pasakyti apie daugumą gedimų. Todėl verta turėti nedidelį stebėjimą. Prie šio puslapio pridėtas workflow veikia pagal grafiką, kiekvienai prijungtai paslaugai atlieka vieną pigią autentifikuotą užklausą ir praneša Jums, kai kuri nors iš jų nustoja teisingai atsakinėti.

Jis tikrina atsakymo turinį, o ne būsenos kodą. Būtent čia klysta dauguma savadarbių stebėjimo sprendimų. Slack užklausa, grąžinanti ok: false su 200, turi būti laikoma klaida, kitaip stebėjimas turės tą pačią akląją zoną kaip ir workflow, kurį jis stebi. Importuokite jį, nukreipkite pranešimų mazgą į kanalą, kurį žmogus tikrai skaito, ir pridėkite po eilutę kiekvieniems Jums svarbiems prisijungimo duomenims.

Tikrinkite dažniau, nei galioja trumpiausiai galiojantis Jūsų tokenas. Daugumai sistemų pakanka kartą per dieną. Jei naudojate Slack rotaciją, tikrinimas kas valandą beveik nieko nekainuoja ir pagauna sugedusį rotacijos ciklą, kol dar nepraėjo 12 valandų. Tas pats principas tinka viskam, ką prižiūrite, plačiau apie tai rašome straipsnyje kodėl AI automatizacijos nustoja veikti po paleidimo.

Šį gedimą tikriausiai sutvarkysite patys

Daugumai prisijungimo duomenų gedimų agentūros nereikia. Jei turite prieigą prie paskyrų, tai vienos popietės darbas, ir už jį mokėti niekam nereikia.

• Atidarykite prisijungimo duomenis n8n ar Make, dar kartą patvirtinkite OAuth sutikimo langą ir pažymėkite visus prašomus leidimus. Nepraleiskite nė vieno vien todėl, kad atrodo nereikalingas: būtent taip atsiranda 403, dėl kurio rytoj vėl teks grįžti.
• Jei tai Google programa, atsidarykite Google Cloud konsolę, raskite OAuth consent screen ir patikrinkite, ar ten parašyta Testing. Publikavimas užtrunka du paspaudimus ir panaikina 7 dienų ribą.
• Perkelkite ryšį nuo asmeninės jį nustačiusio žmogaus paskyros į paslaugos paskyrą (service account) arba bendrą įmonės pašto dėžutę. Pusė mūsų vertintų taisymo projektų prasidėjo nuo to, kad kūrėjas jau buvo išėjęs, o visi prisijungimo duomenys vis dar jo vardu. Tada dešimties minučių pakartotinis prijungimas virsta derybomis dėl prieigos.
• Raskite, kur siunčiami įspėjimai, ir dabar pat išsiųskite ten bandomąją žinutę. Pusėje sistemų, kurias tikriname, įspėjimai keliauja ten, kur niekas nežiūri, o sutvarkyti tai nieko nekainuoja.
• Užsirašykite, prie kurio žmogaus paskyros pririšta kiekviena integracija. Užtenka vieno puslapio. Perdavimo kontroliniame sąraše rasite, kas dar ten turi būti.

Jei po šių žingsnių vykdymai vėl sėkmingi, darbas baigtas ir mokėti niekam nereikia.

Kada verta kreiptis į specialistą

Kreipkitės į mus, kai pakartotinis prijungimas atlaiko tik kelias dienas, kai negalite pasakyti, kiek tylių dalinių gedimų jau buvo, kai administratorius vis atsisako suteikti integracijai reikalingą leidimų sritį arba kai paskyros priklauso žmogui, kuris nebeatsako į Jūsų laiškus nuo kovo. Jei to paties ryšio tokenas vis baigia galioti, problema dažniausiai struktūrinė. Dažnai tai pirmas ženklas, kad tas pats srautas taps nuolat lūžtančiu n8n workflow, jei priežastys nebus išspręstos.

Pradedame nuo raštiškos diagnostikos už 450 €, kurią pateikiame per dvi darbo dienas, o visa jos kaina įskaitoma į tolesnius darbus. Nedideli pataisymai kainuoja nuo 700 iki 1 400 €, standartinis taisymas nuo 1 400 iki 3 700 €, o visas kūrimas iš naujo nuo 3 700 iki 9 200 €. Visiems darbams taikoma 30 dienų garantija klaidoms. Diagnostikos ataskaita lieka Jums: su ja galite kreiptis į bet kurį kitą tiekėją ir gauti antrą pasiūlymą. Būtent todėl ji pateikiama raštu.

Patys prižiūrime kasdien veikiančias sistemas, tarp jų balso administratorių, todėl šiame puslapyje aprašytas stebėjimas užtikrina, kad telefonu būtų atsiliepiama ir sekmadienį. Jei norite, kad šią problemą prižiūrėtų kas nors kitas, pradėkite nuo taisymo paslaugos arba parašykite, kas sugedo. Jei problema platesnė nei prisijungimo duomenys, pradėkite nuo bendro puslapio apie sustojusią automatizaciją.