We have implemented a custom sign-up flow (with a custom domain) for our SPA application. It works well on Chrome, but we keep having issues with Safari.
Here is how I currently see the process and where I think we’re experiencing the issue:
We send a request to Auth0 API using our custom form from our SPA
We get redirected to our custom subdomain. Auth0 handles authentication using our subdomain. The user successfully passes Auth0 authentication
The user is getting a cookie from Auth0
After receiving a cookie, Auth0 forwards the user to the app
The issue starts here. We can not see ANY cookies at all on Safari only. If we manually refresh the page, we start seeing ALL cookies including Auth0 cookie with the token
What am I doing wrong? I sit some Safari bug I've never seen before?
Related
I have a chrome extension which use Oauth to authenticate users. This authentication create cookies which are shared to detect authentication on my other applications.
So when i'm authenticated by oAuth on my extension, i can go on another app and then if i refresh i'm connected without getting login process. This because cookies created by my OAuth process are shared and detected on others app.
This works fine on browser like Mozilla or Opera but don't works on Chrome cause cookies are filtered out with that info message :
this cookie was blocked because its path was not an exact match for or a super directory of the request url's path.(shown on screen by cookies with question mark (AUTH and KEYCLOAK prefixes)
Cookies with AUTH and KEYCLOAK on yellow are filtered out
How could i manage Chrome to accept those cookies ? But more, how could i manage this programmatically on request which have created cookies cause i can't tell my users to modify their Chrome configuration ?
Latest safari update block 3rd-party cookies in iframe. ( https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ )
They offer several solutions to resolve it. I have tried to implement Storage Access API solution, but do like the result.
Can anyone give a hint or a sample flow without technical details on how to implement this:
Option 1: OAuth 2.0 Authorization with which the authenticating domain (in your case, the third-party
that expects cookies) forwards an authorization token to your website which you consume and use to
establish a first-party login session with a server-set Secure and HttpOnly cookie.
firstparty.com has 3rdparty.com in iframe. According to option 1 3rdparty.com authorize via OAuth, receive token. But what does it mean to "forward token to your website to establish login session"? Should 3rdparty.com run login routine as first-party in separate window?
what they are referring to is still having the cookie be a first party (on your website). for example:
user follows this flow:
go to website.com
redirected to oauthSite.com for authentication
ouathSite.com redirects back to website.com with token (or code)
website.com sets token locally on server side code
user now has secure (https only) and HttpOnly (inaccessible to the JavaScript) cookie token that can be used for stateless interactions with website.com
This site seems to go thought the flows quite well:
https://medium.com/#darutk/diagrams-and-movies-of-all-the-oauth-2-0-flows-194f3c3ade85
We are trying to implement SAML logout from a Service Provider/Relying Party to an IdP (in this case, AD FS 3.0). Our logout is not invalidating the session in AD FS. We have narrowed down that the ADFS auth cookies are not being sent in the HTTPS request for some reason, though we have no idea why. This is using HTTPS redirects for the SAML flow.
We have tried to get the request headers the same as the subsequent logon requests which successfully send the cookies, but to no avail.
I have a Fiddler trace that captured multiple logout attempts (and the automatic logins in between). This is in an isolated lab network with dummy data.
Fiddler trace
Any ideas what we could try to get those cookies sent to the AD FS server on the logout request?
The answer, as found by a colleague, was that the redirect request was an XHR request since it started in JavaScript and was not a ‘normal’ browser redirect. Cookies are only allowed to be included on cross-domain XHR requests if the destination server allows the requester access. So, the fix involved terminating the chain of redirects on the XHR request and doing a normal browser redirect. This allowed the browser to send cookies along with the redirect request to the new site.
I am building a django app which requires user authentication for users to surf the web site. I read through many docs and tutorials which say to use set_test_cookie(), test_cookie_worked() and delete_test_cookie() functionality to test whether client's browser supports cookie management.
However this approach requires two requests and views to verify if cookie management is supported in client's browser or not. My question is how to implement Facebook like functionality in cookie management here. Here's how FB handles cookie check -
1) If I am not logged in and I have disabled cookie support then I am not allowed to log in prompting that I must enable cookie support to access my page.
2) Suppose I was logged in before and cookie was set up but I now disable cookie support then if I access facebook.com then it logs me out in just one request and asking me log in again. But if I log in again then it is same as the first case.
3) If I am on my timeline and browsing facebook then without closing that tab if I disable cookie support in browser, I get automatically logged out prompting that cookie support should be enabled.
How does Facebook (same as gmail) know without my sending request that cookie support is disabled in the mid and I get logged out? Does it continuously make Ajax calls to the server? How do I implement this functionality in my django app?
I'm using ember-simple-auth for my Ember app, but I don't have an API endpoint to authenticate users, rather it does a page redirect to the form and signs a user in, then redirects back to my app. (I don't own the authentication)
After authentication, it gets redirected back to me, so I know on the server side when a user has been successfully authenticated. How do I manually authenticate the users' session when they are redirected back to my app?
Currently I did a hack to write two cookies: ember_simple_auth:access_token and ember_simple_auth:authenticator.
I think setting up the session store manually is an ok solution in this scenario as that will trigger the session to be restored after the redirect (which is on startup of the Ember application). I'd maybe configure a custom authenticator that redirects to the external login page in the authenticate method. That way you have that redirect centralized and it will also be triggered automatically whenever Ember Simple Auth automatically enforces session authentication (e.g. from the AuthenticatedRouteMixin).