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
Related
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.
I am writing a native app which uses oAuth. (my app is the client)
At the moment, my app is native to Windows, but I assume that this problem is the same across all desktop operating systems.
To accommodate the oauth flow: My native app opens a browser tab and directs it to the oauth provider.
I am using a browser and not an embedded webview because many Identity providers (ex: google) block non standard browser implementations. ( They want to prevent automated bots).
My app has a small web-server which it uses to listen for the redirect_url called back from the identity provider. Then my app goes on to use said token to access oauth resources from the provider (ex: gmail)
The problem is: When the identity provider (such as google) redirects back to my app, it returns the access_token to my app in the browser's address bar. As such, this token will then appear in the browser history, which will make it very easy for other native apps (or random users using the browser later) to steal my app's token.
What can I do to mitigate this?
How do I prevent the access_token from the oauth callback from showing up in my browser history?
Sounds like you are using Implicit Flow which is the main problem:
Update to Authorization Code Flow (PKCE) so that only a one time use authorization code is returned. Even if an attacker steals it somehow, it will have been used already and the attack will fail.
Another option is to show an Interstitial Page in the browser after login, with a button click to return to your app. As part of that click you can clear the browser tab's history and move to a new location:
history.replaceState({}, document.title, redirectLocation):
See my blog post for some further details on how this looks.
The environment is on single sign on with identityserver3. I have a client angular application which is using openid connect with identityserver 3. I also have a file viewer asp.net mvc application which is used to render pdfs and other files and has no security. The angular app renders the fileviewer inside an iframe to show the contents of files.
I tried adding the file viewer as a client to identity with openid connect so that when a user is signed in to the angular app the user would be single signed into the file viewer app also but it doesn't work in the iframe when file viewer redirects to identity's authorize endpoint due to the x-frame-options sameorigin header. If I open the file viewer url is a separate tab and then launch the file preview within the angular app then calls within the angular app start working as the file viewer cookies are now in the browser.
Ideally I'd like the file viewer to work just like a web api which only validates incoming tokens but not sure how to achieve that with identity server.
How do I go about securing the file viewer application with identityserver? Do I have to manually decode the jwt token by using messagehandlers in the pipeline?
Thanks.
If you were rendering the file locally you could use bearer auth, like webapi does. However because you're using MVC in an iframe, it's slightly trickier. You'll need to trigger the auth for the file viewer in a new window - SSO login should never happen in an iframe. This should then give you auth credentials, usually a cookie, for when you call the file viewer mvc app in your iframe.
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?
i wonder how do desktop apps without any domain names use oauth? or is it not supposed to be used this way? if so what do i use? say for tumblr they have an authentication api so i will have to put the username and password in the url/query string?
i am thinking of using WPF/Adobe AIR. how does something like tweetdeck work?
I've been puzzled by the same question about lack of domain or app url, but it turns out redirection is not the only possible way to complete OAuth authentication process.
I.e., when webapp requests access it provides callback url: the one user will be redirected to when process is completed. That's how webapp know that everything's done.
But you can't redirect to application on user's machine. Thus, there's another way: upon successful authentication server presents special code to the user. Then user copies this code and provides it to application.
You can see both ways described in specification draft.
Also, here's an example of this authentication flow with twitter.
It looks like it may be possible, see googles docs on the subject:
https://developers.google.com/identity/protocols/oauth2/native-app
For a desktop app where a user needs to authenticate himself, you will usually want to use the Authorization code flow.
The approach goes roughly like this:
setup a temporary webserver that listens on the loopback interface
present the login page to the user (either in an embedded browser control or an external browser), with the URL of your temporary webserver as redirect_url
upon successful login, the user will be redirected to your temporary webserver and you can obtain the access code from the code query parameter
Using the access code, you can obtain a token and start making requests using it
Shutdown the temporary webserver
Please note that you will have to allow localhost as redirect URL in your identity provider, in ordrer for this approach to work.
For further details, please take a look at these sample apps from Google.
You should start by reading about getting started with OAuth. Eventually, even a desktop application will open a browser window to authenticate the user - TweetDeck and other Twitter clients do this, as you've probably noticed.
Tumblr, in your example, doesn't use OAuth but rather basic authentication that is being performed via simple HTTP web requests.
Twitter doesn't want users entering their credentials into your application. So at some point the desktop app will need to open a browser window through which Twitter can authenticate their users and return an access token representing the user. From that point the desktop app can use the access token to represent the user in all subsequent API calls to Twitter.
In a desktop environment you have another way to get the token, the browser open url itself.
the OAuth2 server will redirect the users browser to the Redirect URL with the token as a query parameter, so if you control the browser used, you can read the the token directly from the url that the user was redirected to.
Graphical libraries like GKT+ have integrated options to create mini browsers that the user can use to authenticate, and it automatically return the token to the app, but other options are possible, like reading Firefox url for example.