I am using Laravel, an iframe from domain a.com shows my site at b.com, but in user can't log in to my site and no form can be submitted. It sounds Safari blocks all third party cookies (https://stackoverflow.com/a/63478017/6934036) and old solutions not wording on newer version of safari.
Is there a new way to force safari to store cookies from the site in the iframe?
And if there is no correct way, How can I Force Laravel to authenticate user via local storage instead of cookies?
UPDATE:
Cookies SameSite attributes are None with Secure flag.
Both sites use HTTPS.
it works correctly in chrome and Firefox.
For third-party cookies, you need to specify the SameSite attribute as none.
SameSite=None
Also, many browsers currently require that SameSite=None cookies need also to have the Secure attribute, meaning that they require a secure context to prevent being observed by unauthorized devices.
Apple used to be very strict about security and privacy. So probably this is the reason why your cookies are not working.
Related
I've an headless site with a Drupal 9.3.x backend and a Next.js front-end.
The users's authentication is done via simple oauth module in form of "Authorization Code Grant": the user is redirected from the front-end to the Drupal back-end where log-in and then is redirected back to the front-end.
However, on Chrome, I've noticed the Drupal session cookie is "carried" over the front-end.
What's more, if the cookie is deleted from the "front-end" site, the user is log-out even from the back-end, so there is some sort of "connection" between the two.
That cookie is not "linked" with Firefox.
I've notice that the "SameSite" option is set as "None" on Firefox, while is null on Chrome, but I've no idea if that really matters.
Is that normal or is there some sort of bug?
Could be possible to force Chrome\other browser to behave like Firefox?
Screen shot order is:
front-end on chrome
back-end on chrome
front-end on firefox
back-end on chrome
I am working on an app that loads a login page on a WKWebView. My client recently moved to a new MFA provider and this requires the app to allow 3rd party cookies.
I have been trying to allow certain 3rd party cookie but no luck. From hours of research it looks like Apple made this impossible... Is there a workaround to set WKWebView cookie accept policy and/or allow 3rd party cookies from specific domains?
I am trying to have users silently authenticated using Microsoft Azure AD OAuth2. I am calling this url in an IFrame for my online website:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?prompt=none&response_type=code&client_id=XXXXX-XXX&scope=openid profile offline_access User.ReadBasic.All
If the user is logged in this works perfectly on all browsers and returns the authorization code.
However for domain joined machines this does not work for IE & Edge, but does on Chrome..?
For IE & Edge the authorize page returns error=interaction_required. When the prompt=none is removed however from the url and called in a new browser tab it authenticates without any interaction though..
Why do IE & Edge require interaction on domain joined machines, when it apparently does not need it and Chrome works completely fine?
An educated guess is that this behavior is enforced to avoid delivering tokens to applications without the user explicitly being aware of it. iframe-based applications differ from a regular web applications because the former have inherently more security risks associated with them in the form of click-jacking https://en.wikipedia.org/wiki/Clickjacking.
I am building an express server that will be used with an iOS native mobile client.Users of the app will be able to form "parties" with other users, and users within the same party will be able to communicate to each other via socket.io.
I want to enable sessions so that 1) I can have persistent login on my frontend and 2) store user.party_id inside a session, so that for a particular user I always have access to his party. If the user leaves a party, then req.session.party_id will be set to null.
Is is possible to use express-session with a native mobile client? I would assume so, and that all the client has to do is set a cookie header on each request. The server then reads the cookie id, and has access to the user session. Are there any drawbacks to using a session with native mobile clients?
Are there any drawbacks to this approach? Someone suggested that instead I set a JWT as an Authorization header, and on each request, use that header to lookup the user and party_id. This approach seems to be a reinvention of a session.
Check out Swift: How to remember cookies for further http requests for info on how to save a cookie/session cookie.
As to JWT vs. session cookies, they do serve similar purposes. JWT is more widely used today as it enables you to have multiple servers that handle API requests (i.e. horizontal scaling or serverless architectures) and are more fault tolerant (i.e. still work even if the server restarts). Depending on your needs, it might be worth looking at JWTs.
I have a web app split into 2 parts.
A javascript front-end. (myfrontend.com)
API backend (node.js). (mybackend.com)
These 2 parts are hosted on different domains, I need it to be this way because eventually I will build out more front-ends for the same backend (i.e., mobile web apps, etc.)
The way I'm authenticating right now:
A user logs in from myfrontend.com , the credentials are sent (ajax) to mybackend.com where they are checked against the DB. If they don't check out nothing happens and mybackend.com responds with an error code.
If they do check out, I use express.js' cookie-sessions and mybackend.com responds with a cookie (for the mybackend.com domain) . The server links the user-id retrieved from the DB to the session.
From then on, all requests to mybackend.com include the cookie, the backend uses the cookie to find the session, and uses the user-id info in the session to respond correctly.
I had a bunch of CORS issues with this initially, but after setting all the right headers (like withCredentials, etc.) everything is working great, in every browser.
I thought this was a very elegant solution, because all user info is quarantined tightly on the backend, the front-end never receives any user-data, only a short-lived cookie.
So I have 2 questions:
Is this the right way to do this kind of thing? How is OAuth implemented differently from this, and are there advantages?
If I turn off third-party cookies in chrome, this stops working. However turning off third-party cookies in safari still allows this to work fine. What's the deal? Why is getting a cookie for "mybackend.com" when you ajax to "mybackend.com" considered a third party cookie? Would it be ok if I used an iframe or something? Should I worry about this?
Yes, this is a good pattern to use. I used the same approach in http://hackhall.com (https://github.com/azat-co/hackhall). OAuth is more for a three way authentications: consumer, service provider and your app.
OAuth 1.0 requires "oauth dance" to get the the access token which is time sensitive. OAuth 2.0 is easier because after consumers get tokens the first time they can be exchanged for permanent bearers that acts as a password.
OAuth Echo is for delegated calls/requests.
Something to do with the strictness of browsers and/or cookie headers?