OAuth a potřeba veřejné IP adresy

[Filip Jirsák]

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

To těžko. Za prvé by to musel podporovat Fakturoid, za druhé tenhle typ autentizace asi těžko bude chtít Fakturoid podporovat pro aplikace třetích stran, protože by to znamenalo, že uživatel musí vaší aplikaci předat autentizační údaje od Fakturoidu. Což je přesně to, čemu se celý OAuth snaží vyhnout – proto vznikl.

[Reklama]

[Filip Jirsák]

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"?

Na ten link bude Fakturoidem přesměrován prohlížeč uživatele.

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ě".

Role prohlížeče je ta, že přes něj se přihlásí uživatel Fakturoidu a udělí vám přístup. Na základě toho vám Fakturoid (při tom přesměrování) předá token, který budete používat pro přístup jménem toho uživatele.

Pokud to má být dlouhodobý přístup, možná ty tokeny budou dva – refresh token, který bude mít dlouho platnost a uživatel ho může zneplatnit, a ten pak v okamžiku komunikace vyměníte za access token, který bude mít platnost jen pár minut nebo možná hodin, a ten použijete teprve při samotném volání API.

Nainteraktivně to nejde, Fakturoid vám přece nemůže dát přístup k datům všech uživatelů. Musí tam být interakce uživatele, který schválí, že vaše aplikace má mít přístup k jeho údajům.

[Filip Jirsák]

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

To je ale použitelné jedině v případě, kdy jeden uživatel používá svou aplikaci, které důvěřuje a které je ochoten dát své přístupové údaje k Fakturoidu. O tom, že by to byla takováto soukromá aplikace, nebyla nikde v dotazu řeč. Ale je pravda, že to dotaz ani nevylučuje.

Každopádně je potřeba si přečíst ty první tři odstavce dokumentace https://www.fakturoid.cz/api/v3/authorization a rozhodnout se, který typ aplikace máte. Pokud si vyberete „Client Credentials Flow“, tam se redirect URL nepoužívá. Tu položku mají chybně ve formuláři povinnou, tak tam vyplňte libovolné URL.

[bobprasak]

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

To těžko. Za prvé by to musel podporovat Fakturoid, za druhé tenhle typ autentizace asi těžko bude chtít Fakturoid podporovat pro aplikace třetích stran, protože by to znamenalo, že uživatel musí vaší aplikaci předat autentizační údaje od Fakturoidu. Což je přesně to, čemu se celý OAuth snaží vyhnout – proto vznikl.

No ale on to ten fakturoid podporuje - je to te dokumentaci, ze . Jen misto uzivatel/heslo tam mate pouze client_id a client_secret ktery je svazany s tim userem (nicmene v ramci oidc muzete chtit i jmeno a heslo. V kazdym slusnym idp tohle normalne nastavite.

[bobprasak]

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"?

Na ten link bude Fakturoidem přesměrován prohlížeč uživatele.

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ě".

Role prohlížeče je ta, že přes něj se přihlásí uživatel Fakturoidu a udělí vám přístup. Na základě toho vám Fakturoid (při tom přesměrování) předá token, který budete používat pro přístup jménem toho uživatele.

Pokud to má být dlouhodobý přístup, možná ty tokeny budou dva – refresh token, který bude mít dlouho platnost a uživatel ho může zneplatnit, a ten pak v okamžiku komunikace vyměníte za access token, který bude mít platnost jen pár minut nebo možná hodin, a ten použijete teprve při samotném volání API.

Nainteraktivně to nejde, Fakturoid vám přece nemůže dát přístup k datům všech uživatelů. Musí tam být interakce uživatele, který schválí, že vaše aplikace má mít přístup k jeho údajům.

Neinteraktivne to pochopitelne v tomhle pripade take jde . Jen misto jednoho curlu to budou dva. V jednom dostanete code a ten pak ten vymenite za access token. Na redirect se vyprdnete, resp. musite ho specifikovat kdyz zadate o code. Je to dano tim ze vsechny endpointy (jak pro code, tak i pro exchange code/tokeny jsou verejne dostupne). Ten redirect je pouze pro to, aby to moh delat backend. Coz ale v tomhle pripade neni ten scenar kterej tazatel chce.

[Reklama]

[Filip Jirsák]

No ale on to ten fakturoid podporuje - je to te dokumentaci, ze . Jen misto uzivatel/heslo tam mate pouze client_id a client_secret ktery je svazany s tim userem (nicmene v ramci oidc muzete chtit i jmeno a heslo.

Pardon, já jsem to předtím napsal špatně. Při Client Credentials flow se standardně nepředává jméno a heslo, ale identifikace klienta – a klient je ta aplikace, ne uživatel. Takže se tam client_id a client_secret nepředává místo jména a hesla, ale proto, že se to obvykle při Client Credentials flow předávají právě tyhle údaje jako autentizace klienta (= aplikace).

Když se předává přímo jméno a heslo uživatele, je to Resource owner credentials flow.

[Filip Jirsák]

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"?

Na ten link bude Fakturoidem přesměrován prohlížeč uživatele.

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ě".

Role prohlížeče je ta, že přes něj se přihlásí uživatel Fakturoidu a udělí vám přístup. Na základě toho vám Fakturoid (při tom přesměrování) předá token, který budete používat pro přístup jménem toho uživatele.

Pokud to má být dlouhodobý přístup, možná ty tokeny budou dva – refresh token, který bude mít dlouho platnost a uživatel ho může zneplatnit, a ten pak v okamžiku komunikace vyměníte za access token, který bude mít platnost jen pár minut nebo možná hodin, a ten použijete teprve při samotném volání API.

Nainteraktivně to nejde, Fakturoid vám přece nemůže dát přístup k datům všech uživatelů. Musí tam být interakce uživatele, který schválí, že vaše aplikace má mít přístup k jeho údajům.

Neinteraktivne to pochopitelne v tomhle pripade take jde . Jen misto jednoho curlu to budou dva. V jednom dostanete code a ten pak ten vymenite za access token. Na redirect se vyprdnete, resp. musite ho specifikovat kdyz zadate o code. Je to dano tim ze vsechny endpointy (jak pro code, tak i pro exchange code/tokeny jsou verejne dostupne). Ten redirect je pouze pro to, aby to moh delat backend. Coz ale v tomhle pripade neni ten scenar kterej tazatel chce.

Teď úplně nerozumím, o čem píšete. O kterém flow vlastně píšete. V případě Authorization Code Flow vám cUrl nepomůže, protože tam se musí uživatel v prohlížeči autentizovat a může to dělat třeba pomocí biometrie. Pokud píšete o Client Credentials Flow, tam zase nejsou dvě volání – hned prvním voláním dostanete Access Token. Redirect není proto, aby to mohl dělat backend – redirect je způsob, jakým se zpátky aplikaci, která zahájila přihlašování, předá řízení a hlavně jí předá údaje použitelné pro získání Access Tokenu.

[bobprasak]

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"?

Na ten link bude Fakturoidem přesměrován prohlížeč uživatele.

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ě".

Role prohlížeče je ta, že přes něj se přihlásí uživatel Fakturoidu a udělí vám přístup. Na základě toho vám Fakturoid (při tom přesměrování) předá token, který budete používat pro přístup jménem toho uživatele.

Pokud to má být dlouhodobý přístup, možná ty tokeny budou dva – refresh token, který bude mít dlouho platnost a uživatel ho může zneplatnit, a ten pak v okamžiku komunikace vyměníte za access token, který bude mít platnost jen pár minut nebo možná hodin, a ten použijete teprve při samotném volání API.

Nainteraktivně to nejde, Fakturoid vám přece nemůže dát přístup k datům všech uživatelů. Musí tam být interakce uživatele, který schválí, že vaše aplikace má mít přístup k jeho údajům.

Neinteraktivne to pochopitelne v tomhle pripade take jde . Jen misto jednoho curlu to budou dva. V jednom dostanete code a ten pak ten vymenite za access token. Na redirect se vyprdnete, resp. musite ho specifikovat kdyz zadate o code. Je to dano tim ze vsechny endpointy (jak pro code, tak i pro exchange code/tokeny jsou verejne dostupne). Ten redirect je pouze pro to, aby to moh delat backend. Coz ale v tomhle pripade neni ten scenar kterej tazatel chce.

Teď úplně nerozumím, o čem píšete. O kterém flow vlastně píšete. V případě Authorization Code Flow vám cUrl nepomůže, protože tam se musí uživatel v prohlížeči autentizovat a může to dělat třeba pomocí biometrie. Pokud píšete o Client Credentials Flow, tam zase nejsou dvě volání – hned prvním voláním dostanete Access Token. Redirect není proto, aby to mohl dělat backend – redirect je způsob, jakým se zpátky aplikaci, která zahájila přihlašování, předá řízení a hlavně jí předá údaje použitelné pro získání Access Tokenu.

A jakym stylem se tedy uzivatel overi a ziska code ? Samozrejme requestem na endpoint idp (viz treba prihlaseni na google/fb apod a integrace s vlastni aplikaci nebo manage identity v ramci azure). IdP samozrejme muze vyzadovst i nejakej jine mechanismy jako biometrii nebo 2fa ale neni to podminkou, zalezi jak mate nakonfigurovaneho klienta na idp. Pak vam nic nebrani ziskat code curlem a nasledne jinym curlem ziskat token.

[bobprasak]

jinak dve volani v ramci credentials codeflow sem myslel volani navic oproti stavu ktere ma tazatel ted. (musi ziskat token, s tokenem jde na endpoint oproti volam endpoint api klicem)

[bobprasak]

https://support.okta.com/help/s/article/How-to-get-tokens-for-an-OIDC-application-without-a-browser-using-curlPostman?language=en_US

[Filip Jirsák]

A jakym stylem se tedy uzivatel overi a ziska code ?

U typu authorization code grant se uživatel se ověří tak, jak požaduje autorizační server. Jménem a heslem, otiskem prstu, privátním klíčem na tokenu – to je jedno. To řeší autorizační server. Code uživatel nezíská. Získá ho prohlížeč po přesměrování, ten ho předá backendu a backend ho pak vymění za token. Je to proto, aby prohlížeč nemusel znát token a ten zůstal jen na backendu – pokud existuje backend. Pokud backend neexistuje nebo má/může token znát i frontend, vymění code za token frontend.

Pak vam nic nebrani ziskat code curlem a nasledne jinym curlem ziskat token.

Authorization code se dělá proto, aby klient (=aplikace) neznal uživatelovy přihlašovací údaje. Pokud budete uvažovat speciální případ, kdy uživatel používá svého klienta (třeba cUrl), takže mu svěří přístupové údaje, můžete to samozřejmě volat pomocí cUrl – můžete z něj zavolat vše, co posílá prohlížeč. Akorát simulovat třeba přihlášení ke Googlu pomocí Passkey pomocí cUrl bych asi nechtěl.

[neregistrovany]

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

Tak jsem se v těch složenejch zavorkach, jednoduchejch a dvojitejch uvozovkach dočista ztratil, furt mi to píše hlášku o invalidním JSON :-/

Mohl bych vas tedy poprosit o ukazku spravneho formatovani? moc díky!

[neregistrovany]

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

To je ale použitelné jedině v případě, kdy jeden uživatel používá svou aplikaci, které důvěřuje a které je ochoten dát své přístupové údaje k Fakturoidu. O tom, že by to byla takováto soukromá aplikace, nebyla nikde v dotazu řeč. Ale je pravda, že to dotaz ani nevylučuje.

Ano, je to soukromé hejno shell scriptů kterým plně důvěřuji.

[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

Tak jsem se v těch složenejch zavorkach, jednoduchejch a dvojitejch uvozovkach dočista ztratil, furt mi to píše hlášku o invalidním JSON :-/

Mohl bych vas tedy poprosit o ukazku spravneho formatovani? moc díky!

curl -X POST "https://app.fakturoid.cz/api/v3/oauth/token" -H "Content-Type: application/json" -H "Authorization: Basic <BASE64 client_id:client:secret>" -H "Accept: application/json" --data '{"grant_type": "client_credentials"}' -v

# Do authorizacni hlavicky prijde vystup z tohoto prikazu:
echo "$client_id:$client_secret" | base64

Je to bez zaruky - fakturuid nepouzivam ale vypada to cajk:

Kód: [Vybrat]

$ curl -X POST "https://app.fakturoid.cz/api/v3/oauth/token" -H "Content-Type: application/json" -H "Authorization: Basic bXVqY2xpZW50Om1vanNlY3JldAo=" -H "Accept: application/json" --data '{"grant_type": "client_credentials"}' -v
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 174.138.100.186...
* TCP_NODELAY set
* Connected to app.fakturoid.cz (174.138.100.186) port 443 (#0)
.
> POST /api/v3/oauth/token HTTP/1.1
> Host: app.fakturoid.cz
> User-Agent: curl/7.64.1
> Content-Type: application/json
> Authorization: Basic <BASE64 client_id:client:secret>
> Accept: application/json
> Content-Length: 36
>
* upload completely sent off: 36 out of 36 bytes
< HTTP/1.1 401 Unauthorized
.
.
* Connection #0 to host app.fakturoid.cz left intact
{"error":"invalid_client"}* Closing connection 0

[neregistrovany]

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

Tak jsem se v těch složenejch zavorkach, jednoduchejch a dvojitejch uvozovkach dočista ztratil, furt mi to píše hlášku o invalidním JSON :-/

Mohl bych vas tedy poprosit o ukazku spravneho formatovani? moc díky!

curl -X POST "https://app.fakturoid.cz/api/v3/oauth/token" -H "Content-Type: application/json" -H "Authorization: Basic <BASE64 client_id:client:secret>" -H "Accept: application/json" --data '{"grant_type": "client_credentials"}' -v

# Do authorizacni hlavicky prijde vystup z tohoto prikazu:
echo "$client_id:$client_secret" | base64

Je to bez zaruky - fakturuid nepouzivam ale vypada to cajk:

Kód: [Vybrat]

$ curl -X POST "https://app.fakturoid.cz/api/v3/oauth/token" -H "Content-Type: application/json" -H "Authorization: Basic bXVqY2xpZW50Om1vanNlY3JldAo=" -H "Accept: application/json" --data '{"grant_type": "client_credentials"}' -v
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 174.138.100.186...
* TCP_NODELAY set
* Connected to app.fakturoid.cz (174.138.100.186) port 443 (#0)
.
> POST /api/v3/oauth/token HTTP/1.1
> Host: app.fakturoid.cz
> User-Agent: curl/7.64.1
> Content-Type: application/json
> Authorization: Basic <BASE64 client_id:client:secret>
> Accept: application/json
> Content-Length: 36
>
* upload completely sent off: 36 out of 36 bytes
< HTTP/1.1 401 Unauthorized
.
.
* Connection #0 to host app.fakturoid.cz left intact
{"error":"invalid_client"}* Closing connection 0

Tak už hlásí jen Invalid client

* We are completely uploaded and fine
* Connection state changed (MAX_CONCURRENT_STREAMS == 1024)!
< HTTP/2 401
< cache-control: no-store
< content-length: 26
< content-type: application/json; charset=utf-8
< pragma: no-cache
< referrer-policy: strict-origin-when-cross-origin
< strict-transport-security: max-age=63072000; includeSubDomains; preload
< vary: Accept-Encoding,Accept
< www-authenticate: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-request-id: b33c4ac2-8035-4aa9-94d9-cb9d9e20c942
< x-runtime: 0.005270
< x-xss-protection: 0
< date: Fri, 12 Apr 2024 10:57:28 GMT
< alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
<
* Connection #0 to host app.fakturoid.cz left intact
{"error":"invalid_client"}