OAuth a potřeba veřejné IP adresy

[neregistrovany]

Máme na vnitřní síti systém, který si občas tahá data z API služby Fakturoid. Deset let to chodilo přes API token, ale teď přecházejí na OAuth se kterým jsem ještě nepřišel do styku. Co jsem si o tom zatím četl, vypadá to na nutnost mít web server na veřejné adrese (což nemáme a byla by to do určité míry komplikace).

Je to skutečně principiální nutnost, nebo to lze nějak provozovat i bez toho?

[Reklama]

[Filip Jirsák]

Předpokládám, že se vaše aplikace autentizuje vůči Fakturoidu. Pak to obecně není potřeba, protože chodí požadavky z prohlížeče na váš systém, z prohlížeče na Fakturoid a z vašeho systému na Fakturoid. Leda že by tam měli nějaké rozšíření, že by se i Fakturoid chtěl dotazovat vašeho systému – ale obecně pro OAuth tento směr komunikace není potřeba.

[neregistrovany]

Předpokládám, že se vaše aplikace autentizuje vůči Fakturoidu.

ano

Pak to obecně není potřeba, protože chodí požadavky z prohlížeče na váš systém, z prohlížeče na Fakturoid a z vašeho systému na Fakturoid.

Úplně nevím jakou roli v tom hraje prohlížeč. Data z fakturoidu teď taháme curl scriptem. Script zná API token, a jediným HTTP požadavkem je stahne do našeho systému. Toto bychom (pokud to bud emožné) rádi zachovali i s OAuth.

Leda že by tam měli nějaké rozšíření, že by se i Fakturoid chtěl dotazovat vašeho systému – ale obecně pro OAuth tento směr komunikace není potřeba.

Ve formuláři kterým se na stránkách DFakturoidu vytváří "Nová OAuth integrace" je políčko "URL pro přesměrování" ke kterému mi support napsal:

"Link pro přesměrování je URL, které bude volané Fakturoidem během autorizace, je to nedílná součást protokolu OAuth 2.0"

tak právě nevím...

[_Tomáš_]

tak si ten protokol pročti.

Jedná se o adresu, kam tě má fakturoid přesměrovat poté, co dokončí svoji práci, jedná se o web, která stačí, když máš dostupný od sebe a nikoliv z fakturoidu, často to může být klidně localhost (ikdyž to logicky spousta poskytovatelů nepodporuje).

[bobprasak]

Redirect potrebujete hlavne pro authorization code flow, ale koukam letmo na dokumentaci k fakturoidu a podporuje i client credetials codeflow, kde dostanete rovnou access a refresh token na zaklade jmena, hesla, client_id a asi i client_secretu. Pro Vas curl bych zvolil tuto moznost. V podstate se jedna o post na https:<url>/oauth/token. Curl bude vypada pak nejak takhle:

Kód: [Vybrat]

curl -X POST "$URL"
 -H "Content-Type: application/x-www-form-urlencoded" \
 -d "username=$USERNAME" \
 -d "password=$PASSWORD" \
 -d 'grant_type=password' \
 -d "client_id=$CLIENT_ID" \
 -d "client_secret=$CLIENT_SECRET" \
 -d "scope=openid"
Pri requestu na api pak access token nacpete do hlavicky "Authorization: Bearer <ACCESS_TOKEN>". Refresh token si muzete (ale nemusite) ulozit, takze priste si token vyzvednete pres nej a ne pres username/password

https://www.fakturoid.cz/api/v3/authorization#client-credentials-flow

[Reklama]

[bobprasak]

Jinak authorization code flow (kdy potrebujete ten redirect) se pouziva hlavne ve chvili, kdy chcete aby Vas backend dostal primo access token a token nesel na frontend. Pak Vam IdP vyda pouze kod a redirect na Vasi cast backendu, ktera s timto auth codem provola znovu idp a dostane access a refresh token. Na zaklade nich Vas backend jedna jedna autentizuje (jste prihlasen) a na zaklade claimu a pozadovaneho scopu muze i authorizovat, tzn svazat Vassi session s konkretnimi pravy na danych endpointech. Vyhoda je i podpora ruznych public idp jako facebook, google apod, kdy na zaklade uctu na techto platformach ziskate opravneni do nejake 3rd (klidne Vasi aplikace). Pokud touzite si rozchodit vlastni idp pak doporucuji treba keycloak, pripadne na stejnych principech stoji tusim i azure ad. OIDC vladne svetu

[Filip Jirsák]

V OAuth vystupují 4 subjekty:

• Autentizační server (k tomu se uživatel přihlašuje, třeba tam zadá jméno a heslo) – ve vašem případě Fakturoid
• Resource server, poskytovatel dat – server, který má data, ke kterým chcete získat přístup. Ve vašem případě také Fakturoid.
• Služba, která chce získat přístup – to je váš backend.
• Uživatel a typicky jeho prohlížeč – ten, kdo uděluje přístup službě ke zdrojům, váš uživatel.

Celé to pak vypadá tak, že uživatel chce vaší službě předat nějaké údaje. Takže navštíví vaši službu, ta ho přesměruje na autentizační server. Tam se přihlásí svými údaji a je přesměrován zpět na vaši službu, ale v rámci přesměrování získá i přístupový token. A tento token už může vaše služba využít pro přístup ke požadovanému zdroji.

Vtip je v tom, že uživatel nepředá své přihlašovací údaje k Fakturoidu vám, ale použije je přímo na Fakturoidu, kde třeba ještě může říct, k čemu můžete mít přístup. Třeba že můžete jen vytvořit novou fakturu, ale ne získat informace o ostatních fakturách (teoreticky, nevím, zda to tak zrovna Fakturoid má). Vy pak máte token (obvykle s omezenou časovou platností), který vás opravňuje v omezeném rozsahu volat služby Fakturoidu jménem uživatele.

Zároveň uživatel nemusí někde generovat nějaké tokeny a vkládat je do vaší aplikace, ale normálně se přihlásí na stránce Fakturoidu tak, jak je zvyklý.

Ta URL pro přesměrování právě svědčí o tom, že se používá přihlašování přes prohlížeč (pravděpodobně code flow). A je to URL, kam bude uživatel přesměrován po té, co se na Fakturoidu přihlásí. Tedy to musí být adresa, která je dostupná z uživatelova prohlížeče. Nemusí to být veřejná adresa, Fakturoid se k ní nebude připojovat, je jen pro toho uživatele (resp. jeho prohlížeč).

[neregistrovany]

tak si ten protokol pročti.

Jedná se o adresu, kam tě má fakturoid přesměrovat poté, co dokončí svoji práci, jedná se o web, která stačí, když máš dostupný od sebe a nikoliv z fakturoidu, často to může být klidně localhost (ikdyž to logicky spousta poskytovatelů nepodporuje).

Já  si o něm četl, ale úplně jsem to zatím nepobral.

Píšou tam "url bude volané fakturoidem" (což chápu jako "ze severu fakturoidu"), jak se dostane fakturoid na muj localhost (za firewallem) netusim.

[bobprasak]

pouzijte client credentials a neresite zadnej redirect . Je to jen jeden curl navic a parsovani tokenu pres jq.

[neregistrovany]

Tedy to musí být adresa, která je dostupná z uživatelova prohlížeče. Nemusí to být veřejná adresa, Fakturoid se k ní nebude připojovat, je jen pro toho uživatele (resp. jeho prohlížeč).

Proč tedy ze supportu píšou "link pro přesměrování bude VOLÁN FAKTUROIDEM během autorizace". Nebo tím myslí "javascriptem fakturoidu běžícím v browseru"?

Navíc jsem už psal že u mě teď žádný browser nehraje roli, vše se děje pomocí scriptů. Třeba výpisy se tahají schedulovaně na pozadí... "user" (token) je stále stejný (dokud exepiruje). Prostě necháput tu roli browseru v tom procesu, přece se to musí dát udělat nějak "neiteraktivně".

[neregistrovany]

pouzijte client credentials a neresite zadnej redirect . Je to jen jeden curl navic a parsovani tokenu pres jq.

To bych právě moc rád, ale při registraci OAuth tam Fakturoid vyžaduje to redirektovací URL, bez toho nejde se k jejich OAuth nejde registrovat.

[bobprasak]

ne nevyzaduje, kdyz si tu dokumentaci prectete poradne, tedy dojedete az nakonec tak credentials flow se nijak nenastavuji pouze ziskate sve client_id a client_secret (pak je tam odkaz na rfc). A s temito informacemi pak zavolate ten curl co jsem   Vam poslal vyse a mel byste dostat token s response code 200. Zadnej redirect.

Before you start go to your Fakturoid account and download your Client ID and Client Secret from your user screen Settings → User account.

https://www.fakturoid.cz/api/v3/authorization#client-credentials-flow

[_Tomáš_]

Pokud je nelogicky vyžadují ve formuláři, tak tam nějakou url zadej, zkus třeba ten localhost, to se pak dobře ladí, pokud jí nepoužiješ a fakturoid umožňuje volat oauth/token, je jedno co tam je.

Podpora asi píše o prohlížeči a volání url, protože použití v prohlížeči je pro ně nejčastější, nerozumí přesně tomu jak to funguje (stejně jako ty). Prohlížeč si nahraď za curl, ten protokol je poměrně jasně popsaný.

[neregistrovany]

ne nevyzaduje, kdyz si tu dokumentaci prectete poradne, tedy dojedete az nakonec tak credentials flow se nijak nenastavuji pouze ziskate sve client_id a client_secret (pak je tam odkaz na rfc). A s temito informacemi pak zavolate ten curl co jsem   Vam poslal vyse a mel byste dostat token s response code 200. Zadnej redirect.

Before you start go to your Fakturoid account and download your Client ID and Client Secret from your user screen Settings → User account.

https://www.fakturoid.cz/api/v3/authorization#client-credentials-flow

Tak jsme to zkusil, snad to mam dobre

curl -X POST "https://app.fakturoid.cz/api/v3/oauth/token" -H "Content-Type: application/x-www-form-urlencoded" -d "username=muj_login_do_fakturoidu" -d "password=moje_heslo_do_fakturoidu" -d "grant_type=password" -d "client_id=moje_id" -d "client_secret=muj_secret" -d "scope=openid"

ale vyhodilo to error

{"error":"invalid_request","error_description":"Only JSON requests are allowed."}

[bobprasak]

aaa jasny, nevsim sem si ze ten odkaz na ten POST v fakturuid dokumentaci pro cloent credentials je klikaci a je tam priklad kde maj bejt jaky hodnoty. Bohuzel ted nejsem u pocitace, zkuste to sam a kdyby to neslo pastnu to vecer