5 ms·
I find this very annoying. An OpenID Connect provider is perfectly capable of working without using third-party cookies. The only reason they need them is to al
by thinkharderdev 6y ago
I find this very annoying. An OpenID Connect provider is perfectly capable of working without using third-party cookies. The only reason they need them is to allow OIDC authentication without actually redirecting to the provider (by using a hidden iframe to do the OIDC flow on the same site). But if 3rd-party cookies are disabled it should just fall back to the normal OIDC redirect.
- jsmith45 6y agoThe OIDC front channel signout functionality relies on third party cookies to work properly. This feature has the IDP basically loading your app's end session page in a hidden iframe. Similarly the OpenID Connect Session Management feature (check_session_iframe) also depends on the ability to use third party cookies. This functionality is needed to be able to detect if user logged out from front-end code without relying on having any back end code that could receive either a front-channel or back-channel signout notification and send it back. In the absence of that a pure SPA with no backend could only detect the logout if access tokens are stateful, and they get an error message back that the token refers to an ended session. Some people get really cranky if a single sign out feature does not actually sign you out of everything.
- thinkharderdev 6y agoSorry you're right. I was just thinking about sign in. But at the same time it seems like the cat is already out of the bag on this one. Safari already blocks all third party cookies by default and it seems like other browsers are moving in the same direction.