Closed max-1004 closed 3 years ago
Error in OpenIdConnect:Unable to determine state" on the screen.
Which IdP? Which browser?
(Most likely Chrome - CSP policies are suppressing cookies ...... ref https://charliedigital.com/2020/01/22/adventures-in-single-sign-on-samesite-doomsday/ A workaround is to comment this line https://github.com/owncloud/core/blob/736e54aa571658b9f1a31f9a27a3ff877b2a3006/lib/private/Session/CryptoWrapper.php#L102)
IdP provider is cidaas by WidasID (https://www.cidaas.com/) As Browser I use Firefox 82.0.3 (64-Bit) and also tried Chrome Version 87.0.4280.66(64-Bit)
IdP provider is cidaas by WidasID (https://www.cidaas.com/)
We did not yet test this Idp (actually never heard of it until now ;-) ) ....
Please give it a try to comment the line as suggested above (+restart apache to be sure the changes are properly applied -one never knows ....)
'provider-params' => [ 'authorization_endpoint' => 'https://widas.cidaas.de/authz-srv/authz', 'token_endpoint' => 'https://widas.cidaas.de/token-srv/token', 'token_endpoint_auth_methods_supported' => 'client_secret_basic,client_secret_post,client_secret_jwt,private_key_jwt', 'userinfo_endpoint' => 'https://widas.cidaas.de/users-srv/userinfo', 'end_session_endpoint' => 'https://widas.cidaas.de/session/end_session', 'jwks_uri' => 'https://widas.cidaas.de/.well-known/jwks.json', 'grant_type_supported' => 'implicit,authorization_code,refresh_token,password,client_credentials' ]
FYI: since https://widas.cidaas.de/.well-known/openid-configuration exists you don't need to declare all these values ....
'openid-connect' =>
array (
'provider-url' => 'https://widas.cidaas.de',
'client-id' => 'd349752d-9801-427c-9634-ac130577xxxx',
'client-secret' => 'XXXX',
'loginButtonName' => 'cidaas',
'autoRedirectOnLoginPage' => false,
'mode' => 'userid',
'search-attribute' => 'sub',
'scopes' => ['openid','email','profile','identities','groups','roles','offline_access','phone','adress'],
),
I removed the provider-params and commented "samesite" => 'strict' out. But now my ownCloud shows only a white screen before the login page with 599 Broken
array (
'provider-url' => 'https://widas.cidaas.de',
'client-id' => 'd349752d-9801-427c-9634-ac130577xxxx',
'client-secret' => 'XXX',
'loginButtonName' => 'cidaas',
'autoRedirectOnLoginPage' => false,
'mode' => 'userid',
'search-attribute' => 'email',
'scopes' => ['openid','email','profile','identities','groups','roles','offline_access','phone','adress'],
),
'memcache.local' => '\OC\Memcache\APCu',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
'host' => 'localhost',
It works now. Thank you a lot! I took a snapshot and did the steps again.
with 599 Broken
usually a sign of some fatal error - there is a crash report file in the data folder .... FYI for the next time ;-)
In order to really fix the problem - the IdP can send this header in the redirect back to OC - this will allow the browser to include the strict cookie. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site
You might want to get in touch with the devs of cidaas ;-)
Okay, thank you very much for your help!
@DeepDiver1975 this is unclear to me and probably should be reopened. Imo the issue is that the ownCloud cookies use SameSite: strict
(https://github.com/owncloud/core/blob/736e54aa571658b9f1a31f9a27a3ff877b2a3006/lib/private/Session/CryptoWrapper.php#L102) and thus when coming back as redirect from an IdP on another origin, the request to ownCloud does not contain any cookies.
There is nothing which can be done about that, except maybe disabling security via Sec-Fetch-Site which is not the best of ideas.
Also disabling SameSite: strict
for all cookies is obvisouly bad.
Imo, what needs to happen here is that the ownCloud callback request endpoints must ensure they work then called from another origin, either by avoiding to store data needed by the callbacks in a cookie or making that cookie (and only that) using SameSite: lax
.
With kopano konnect it works because of the sec-fetch header. From my pov it is better to work with an explicit exception using this header then relaxing same site settings for the whole application.
With kopano konnect it works because of the sec-fetch header.
@DeepDiver1975 OK - then I do not understand it - can you explain where to set this header and to what value? Who does set it in the first place? Afaict we do not set such a header in Kopano Konnect.
I'll look through my notes and let you know asap.
@DeepDiver1975 after investigating this a bit more, i think this problem needs a fix on ownCloud side.
ownCloud sets two cookies (oc_sessionPassphrase, and the one with the dynamic name), both use SameSite: strict
and thus are not sent to the apps/openidconnect/redirect
endpoint when coming back from the IdP running on a different origin.
Those cookies are required by the redirect endpoint to complete the OIDC flow, means OIDC does not work if the IdP is not sharing the ownCloud origin.
Hello, I am working on moving our current ownCloud from LDAP to OIDC. For this I have created a new ownCloud instance. When I tried to log in via the OIDC provider cidaas after activating OpenID Connect, I got the error 503 "Service Unavailable" and saw the message " Error in OpenIdConnect:Unable to determine state" on the screen. I tried it already with different configuration parameters, but every time the same result. It is the first time I work with OIDC and I have no more ideas. Can someone please help me and have an idea what the problem might be? Here is my config.php:
Please let me know if some configurations/information that you need to find the problem are missing. Thank you.