I am using the standard OIDC .NET library to make a challenge request to ADB2C. From my understanding, this automagically attempts the sign in with the refresh token in cache and gains an authorization without re-asking for credentials.
This seems to work absolutely fine, except on 1 browser - Chrome on Android. No matter what I try, this browser seems to to lose the refresh token, so after around 1 hr, it starts asking for credentials again. I have cross checked this on Chrome web/mac, edge, IE, safari, FF and they all behave as expected to maintain a constant logged in state.
Any ideas? This should be browser independent from what I understand, but maybe I'm missing a trick?
Update
This seems to be similar behaviour even when accessing a web app protected by AD. Again, Chrome loses the refresh, but other browsers are fine.
Update
I see this in Fiddler when trying to access the site after the expired token
Chrome
Set-Cookie: x-ms-cpim-csrf=XXX; domain=auth.mywebsite.com; path=/; SameSite=None; secure; HttpOnly
Edge
Set-Cookie: x-ms-cpim-sso:mytenant.onmicrosoft.com_0=XXX; domain=auth.mywebsite.com; path=/; SameSite=None; secure; HttpOnly
So yes there is a difference, but why and how to fix?
It could be the issue with SameSite cookies in Chrome that causes he cookies to not be sent as you expect. Here's a few pointers to help you out:
How To Prepare Your IdentityServer For Chrome's SameSite Cookie Changes - And How To Deal With Safari, Nevertheless
Upcoming Browser Behavior Changes: What Developers Need to Know
But I think first of all you should verify if this is a SameSite issue, by using a tool like Fiddler to capture the traffic and verify that the cookies are indeed lost. Do compare in Fiddler your different browsers and see if there's some differences.
Do try to login using a incognito mode, so that you start with no cookies in the browser. Then you should see the cookies being set both by your identity provider and your application.
In Fiddler you can under the Filter tab enable the first item in the picture to flag responses that set cookies, to make it even easier to detect when cookies are set.
Related
I ran into such a problem.
When I run the application on my laptop (Linux/Ubuntu 18) in the developer console in the Chrome browser, I have this message
A cookie associated with a cross-site resource at
http://pubsub.rtschannel.com/ was set without the SameSite
attribute. A future release of Chrome will only deliver cookies with
cross-site requests if they are set with SameSite=None and Secure.
You can review cookies in developer tools under
Application>Storage>Cookies and see more details at
https://www.chromestatus.com/feature/5088147346030592 and
https://www.chromestatus.com/feature/5633521622188032.
On another laptop (Linux/Ubuntu 16) in the Chrome browser, when the application is launched locally, there is no such message.
I tried to find at least some information on this subject, but alas I couldn’t. The only thing I could find was the link inside the message that it was a browser bug and in Chrome version number 80 it should be fixed and this setting would be added by default.
Please tell me, does it depend on the browser settings, or can I somehow influence this message programmatically? Can I clean it somehow?
On the project, I use angularjs if this can help.
Thanks.
These warnings are purely informational at the moment and do not affect site functionality. This behaviour will not be enforced until Chrome 80 which is due to hit stable in Feb 2020.
You can simply turn off the messages by setting chrome://flags/#cookie-deprecation-messages to Disabled. However, that is purely affecting the display of the messages.
If the pubsub.rtschannel.com is not your domain, e.g. it's a third-party service you use, then it's that domain that will be responsible for updating the cookies.
If it is your domain, then you need to review the cookie usage and set an appropriate value for the SameSite attribute on the cookie. You can find more context and guidance on https://web.dev/samesite-cookies-explained.
I set the HSTS header on my site and i want to test that the different browsers (chrome, Firefox, IE, Opera) do enforce the header.
I set a trusted certificate, connect to the site and I can see the the header at the HTTP response. but i want to validate that the browser do enforce the protocol.
In Chrome it's easy and it works:
- I can query the site at chrome://net-internals/#hsts
- When trying to connect with HTTP i get 0kb response with status 307.
- If i change back self-signed cert i can't connect the site and there is no proceed option.
The other browsers behave differently, i can't query the HSTS list, the response status and size is different and when changing to self-signed cert (after first trusted connection) i do have proceed option.
So how can i validate that the protocol is enforced on each browser?
Although Chrome's ability to query the HSTS cache and see the fake 307 redirect is handy, you can just check whether HSTS is enforce.
HSTS offers you two options:
Automatically load HTTP resources over HTTPS
Prevent click through of cert errors.
You are concentrating on the second option, but why not use the first option as the test? Just load the site up with the HTTP and check whether it is redirected (i.e. loads HTTP URL and so is not using a HSTS rule) or if it just loads HTTPS URL immediately (i.e. is using HSTS).
So in Firefox for example open network tools click on "Persist logs" option (and let's do "Disable Cache" to avoid any confusion). Then go to a site which has an HSTS header over HTTP (e.g. http://stackoverflow.com) and you'll see a 301 redirect if this is your first visit:
Next time you go to it (after it has cached the HSTS header) it should go directly to the HTTPS URL even though you typed the HTTP URL in address bat:
If you've already been on stackoverflow.com then you can clear the HSTS cache to try this again.
Once you've confirmed that HSTS is being used or not, you can then investigate the click-through issue. Browsers should not allow click through when HSTS is in place, including for self-signed certs, but maybe there's a bug, or it's still cached your old cert in some places, or the HSTS policy has expired or something else...
When I access the URL http://kgnzb.rvxrg.servertrust.com/login.asp using Chrome, I can see that there are 3 cookies in the browser. Using Chrome Developer tools with Javascript disabled to view the cookies.
However when I look at the Fiddler traffic, I see only two cookies. Screenshot http://prntscr.com/27pecx.
I see the same behavior as Fiddler when I scrape the page also.
Could some one explain why Fiddler and the Scraper sees only two cookies where the browser sees 3 cookies?
Thanks
Fiddler shows you exactly what is sent to and from the server.
You're only showing the Set-Cookie responses of one HTTP response; those are the cookies set by only that response.
If you want to look at all cookies being sent to the server for a request, look at the Request Header Inspector's Cookie value for a subsequent request.
This web page is made up of multiple resources, each of which may include a Set-Cookie header. Also, when JavaScript is enabled, cookies can be added or removed by manipulating the document.cookie property. Such changes would only be observable on the network in a subsequent request.
I have successfully tested HTML5 Application Cache under Chromium. For instance:
CACHE MANIFEST
http://localhost/pycoh-mnt/materialRequisition/create
The above URL renders an HTML5 file. When I protect it with cookie-based authentication, Firefox 11 fails; I get an error whose description I could not find, but I think is due to an HTTP Redirect response. If I make the URL public, it correctly caches it.
In the other hand, Chromium 18 handles the caching properly in both cases. I'm afraid Firefox is not sending the cookie information when it issues the caching request.
Any idea? Thank you!
PD. I forgot to say I'm running 64 bits apps.
Check if third party cookies are disabled in FF. There is currently a bug in FF that prevents cookies from being sent in the manifest request when 3rd party cookies are disabled:
http://bugzilla.mozilla.org/show_bug.cgi?id=722683
Does the checkmark at the Http column of Chrome devtool's Cookie resource panel indicate a HttpOnly cookie?
I can't find docs that confirm this, though I suspect it is the case. I am trying to verify my app is using HttpOnly for session cookies.
Yes. Enter document.cookie in the console, and you'll see that none of the checked cookies are visible.
HTTP = HttpOnly flag, Secure = secure flag.
Yes. Right click on your page or press F12 button. This will open developers tools window. Go to application tab. It'll show as follow :-
Now, typing document.cookie on the tab, you'll see only csrf token being shown.
To specify session cookies to be httpCookie by default, set 'useHttpOnly' attribute in context.xml in tomcat, for java web application. For more information, refer to http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Common_Attributes
So 2 things .
1) HTTP only cookie this name is a bit misleading as we can send HTTPOnly cookie over HTTPS and it works perfectly fine. Main characteristics of HTTP Only cookie is it can't be accessed using JavaScript . In-fact You can't even manually edit this in Chrome's Application tab.
2) So how you can edit HTTP Only cookie ? In chrome You can use extension to edit cookie while development . In production mode there is no way you can adultrate this without man in the middle attack on HTTP connection.
Today (May 2016), googling around for the same reason, I found this question and this page from developers.google.com explaining:
HTTP: If present, indicates that cookies should be used only over HTTP, and JavaScript modification is not allowed.