Cloudflare access u nastavení Oauth2 požaduje jwks_uri jako certificate url, např. mojeid jej má na https://mojeid.cz/oidc/key.jwk
Viz https://developers.cloudflare.com/cloudflare-one/identity/idp-integration/generic-oidc/#1-create-an-application-in-your-identity-provider
na jaké adrese můžu najít url seznam certifikátu?

Vidím, že se na to ptal někdo jiný už v https://napoveda.seznam.cz/forum/threads/173336/1 ale zůstalo to bez odpovědi.

Také nemůžu najít well_known_configuration, zkoušel jsem
https://login.szn.cz/api/v1/.well-known/openid-configuration
https://login.szn.cz/api/.well-known/openid-configuration
https://login.szn.cz/.well-known/openid-configuration
a nic z toho nefunguje

Here’s a concise reply in paragraph form:

The [jwks](https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-sets)_uri or certificate URL is typically a well-known URI that follows the standard .well-known path defined in OAuth and OpenID Connect specifications. This allows clients to automatically discover the public keys needed to verify JWTs or tokens without manual configuration. Ensuring it is correctly exposed and accessible is essential for secure token validation.

Nejsem si jisty, co znamena "nepožaduje call back serveru přijímajícího autorizaci". Budete laskav, kdyz to trochu upresnite.

Skutecnost je takova, ze Seznam nabizi OAuth a nikoliv OIDC, to je cele. Jestli se to do budoucna zmeni, to neumim odhadovat -- aktualni reseni dovoluje treti strane delegovat prihlaseni na Seznam a ziskat potrebna data o prihlasenem uzivateli. Dalsi navysovani miry komfortu partneru by jiste bylo mile, ale fakticky a technologicky nikoliv nezbytne. Verim, ze veskera data, ktera o uzivateli Seznam timto zpusobem nabizi, je mozne ziskat i bez pouziti OIDC/JWT.

Děkujeme za zprávu. Bohužel nepoznám zda máte insider informace nebo je to jen konstatování na základě pozorování vnějšího uživatele.

Nicméně když si dovolím o tom zde zauvažovat, tak vlastně "původní" response type code a pokročilejší id_token se nějak přirozeně vyvinul či rozšířil do JWT (JSON Web Token) viz standard proposal "JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)". Musím říci, že jeho použití je obecně o dost jednodušší a technicky vzato je i o hodně chytřejší (například nepožaduje call back serveru přijímajícího autorizaci).

Vlastně když to vezmu racionálně je to evoluční a přirozené rozšíření OAuth2 (OIDC) a jako takové ještě více zpřesňuje a odděluje poskytovatele(providera)/(vydavatele)issuera authetizace od samotného poskytovatele. A právě doplnění o možnosti všech těch JSON... (JWA, JWS, JWE, JWT, JWK, JWKS) mi přijde v pravdě geniální a hlavně celkem standardizované. A hlavně elegatní ať už se shared secret, RSA, EC, či budoucími algoritmy.

Což mne přivádí k otázce zda může existovat technický důvod pro by Seznam.cz neměl chtít být poskytovatelem takové formy authetizace pro třetí strany, když to technicky až tam moc nestojí.

sluzba Prihlaseni pres Seznam neposkytuje data ve formatu podepsanych tokenu (JWK a podobne). Proto ani neprichazi v uvahu zadny certifikat s verejnym klicem, pomoci ktereho by bylo mozne podpis overit.