1987563 - icloud logins are sometimes broken (if you somehow ended up with an invalid `aasp` cookie for Domain:".idmsa.apple.com")

Status: VERIFIED FIXED

(Web Compatibility :: Site Reports, defect, P1)

Description

[Jeff Muizelaar [:jrmuizel]]

See:

https://support.mozilla.org/en-US/questions/1534464
https://support.mozilla.org/en-US/questions/1534445

I'm also not able to login. But it works in private browsing mode.

Comment 1

[Denys [:denyshon]]

Another report:
https://support.mozilla.org/questions/1534409

Comment 2

[Jeff Muizelaar [:jrmuizel]]

In the case where it's failing I get 401 error on GET https://idmsa.apple.com/appleauth/auth

Comment 3

[Jeff Muizelaar [:jrmuizel]]

bgrinstead and pbone were not able to reproduce

Comment 4

[Kelimutu [:kiki]]

For reference, a similar issue reported recently which managed to be fixed by clearing cache, cookies, and site data.

Comment 5

[Jan Brasna [:janbrasna]]

Attachment: 2025-08-31-12-02-44-b2f66a.png

Comment 6

[Jan Brasna [:janbrasna]]

BTW the user report from sumo notes also being unable to log in with a passkey, not just username+password.

(Their report is more than a week old FYI.)

Comment 7

[Jan Brasna [:janbrasna]]

There are reports coming from Windows 10–11, macOS 11–15 and Gentoo, all on recent v142.x

https://github.com/webcompat/web-bugs/issues/175172

Comment 8

[Jan Brasna [:janbrasna]]

According to https://github.com/webcompat/web-bugs/issues/176202 it works in v141.x (tho not mentioning if tested at the same time).

Comment 9

[Kelimutu [:kiki]]

2 more users noting that clearing site data fixed the issue in this thread.

Comment 10

[Bruce MacAlister]

Based on the notes i tried Firefox private window and clearing history and cookies. The failure remains.

Comment 11

[Jeff Muizelaar [:jrmuizel]]

Bruce, do you see: Cookie “aasp” has been rejected because it is in a cross-site context and its “SameSite” is “Lax” or “Strict”. in the dev tools console when you try logging in?

Comment 12

[Jan Brasna [:janbrasna]]

Please note Bruce uses a Snap version, so he's bug 1983681 in the first place.

Comment 13

[Bruce MacAlister]

Jeff, with "Firefox 142.0.1 Mozilla Firefox Snap for Ubuntu canonical-002-1.0" I get:
XML Parsing Error: no root element found
Location: https://idmsa.apple.com/appleauth/jslog
Line Number 1, Column 1: jslog:1:1
XHRPOST
https://idmsa.apple.com/appleauth/auth/signin/init
[HTTP/1.1 503 Service Temporarily Unavailable 26ms]

XHRPOST
https://idmsa.apple.com/appleauth/jslog
[HTTP/1.1 400 89ms]

XHRPOST
https://idmsa.apple.com/appleauth/auth/signin?isRememberMeEnabled=true
[HTTP/1.1 503 Service Temporarily Unavailable 543ms]

XML Parsing Error: no root element found
Location: https://idmsa.apple.com/appleauth/jslog
Line Number 1, Column 1: jslog:1:1

Comment 14

[Daniel Holbert [:dholbert]]

Thanks, Bruce! Sorry for the stray request - per comment 12 we're now pretty sure you're just hitting bug 1983681 which has an unrelated-to-cookies root cause (though it results in the same user-facing problem).

I think I have steps-to-reproduce here that are good in Firefox vs. bad in Chrome; I'll post those shortly.

Comment 15

[Daniel Holbert [:dholbert]]

STR, starting with a fresh profile:

1. Visit https://www.icloud.com/
2. Click "Sign In"
3. Open DevTools and find the cookies section, specifically looking for https://idmsa.apple.com
   (in Firefox, it's the "Storage" tab; in Chrome, it's the "Application" tab)
4. Find the cookie called "aa" (which has Domain set to .idmsa.apple.com) and change its name to aasp and its value to 12345
5. Click into the username field, and proceed to log in with username/password.

In Firefox, this produces the "bad results" here -- a popup appears with Failed to verify your identity. Try again, but nonetheless my other apple devices get a 2fa notification to allow the login (which is an indication that I did type my credentials correctly).

In Chrome, this produces "good results" -- I advance to a 2fa-code-entry screen (and get a 2fa notification on my other apple devices which will bypass that screen).

BUT, if I perform the STR in Chrome and I use their DevTools to make the edited cookie have SameSite value of None, then Chrome matches Firefox's bad results.

Comment 16

[Daniel Holbert [:dholbert]]

so, it seems the issue here is that
(1) (for unknown reasons) Apple/icloud handed out some bogus aasp session cookies for domain idmsa.apple.com (or they purged some previously-valid session cookies cookies on their end).
(2) Firefox users who received those cookies treat them as SameSite=None by default (whereas in Chrome, they're treated as SameSite=Lax; and in Safari, we think this cookie is just blocked as being a third-party cookie)
(3) iCloud login is apparently not robust in handling the situation where a user has a bogus aasp session cookie with SameSite=None (regardless of browser)

(1) and (3) appear to be things going wrong on the iCloud/Apple side; but they result in a Firefox-specific issue due to (2).

Comment 17

[Daniel Holbert [:dholbert]]

Side note: Chrome's SameSite=Lax behavior happens to help here because it prevents the aasp cookie from being included in the request to 'https://idmsa.apple.com/appleauth/auth. So it's as if the cookie's not set at all, for the purposes of this login flow, basically.

So it's possible https://idmsa.apple.com/appleauth/auth just chokes on any aasp cookie at all (i.e. it's not expecting any such cookie to be present).

Comment 18

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #17)

So it's possible https://idmsa.apple.com/appleauth/auth just chokes on any aasp cookie at all (i.e. it's not expecting any such cookie to be present).

Update: this^ guess wasn't quite true; Apple does accept some aasp cookies.

Specifically: if I follow my STR in comment 15, but instead of value 12345 I instead carefully copypaste the cookie-value that the https://idmsa.apple.com/appleauth/auth/authorize/signin frame is trying-and-failing to set (failing with the error message in comment 11), then I am able to sign in successfully.

So:

• If I use the aasp session-cookie-value that Apple has just tried-and-failed to give me (in an attempted SameSite=Lax cookie, which I manually save to a SameSite=[unspecified] cookie), then everything works out fine.
• But if I instead use the aasp session-cookie that somehow pre-exists in my current Firefox session and has SameSite unspecified, then I get login failures as described in this bug.

Comment 19

[Daniel Holbert [:dholbert]]

We've been in touch with contacts at Apple and got to an understanding of what happened here; and they're going to ship a change on their end that should fix this, hopefully within a few days.

Expanding on the background/history in comment 16 to explain how we got here:
(1) iCloud.com does its authentication using an iframe pointing at https://idmsa.apple.com/
(2) idmsa.apple.com uses a cookie called aasp as an optional piece of its authentication -- if that cookie is present, it must be valid/recognized or else the authentication will be rejected (even if the user types in a valid username/password). But if this cookie is absent from the request, then its absence doesn't appear to be a deal-breaker for authentication (that's why clearing cookies has helped here, per comment 4).
(3) Until very recently, this idmsa aasp cookie was created with SameSite unspecified, which Firefox treats as "None". Firefox users who visited iCloud.com in the past may have such cookies stored in their cookie database.
(4) This "idmsa" identity-management service recently deployed an update which made them start specifying SameSite=Lax for this cookie instead.
(5) That change makes Firefox (along with other browsers) reject attempts to set a new value for this cookie on iCloud's idmsa iframe, because that iframe is considered to be cross-site, SameSite=Lax cookies must be rejected in that context.
(6) So: affected Firefox users are left with their old value of the cookie -- the value they got in (3). These old cookie-values continue to be sent as part of their authentication requests, and they're unrecognized by Apple, so they cause authentication to be rejected per (2).

Why is this only affecting Firefox users? This situation appears to uniquely affect Firefox because other browsers have always rejected the all-important "aasp" cookie (when set by the idmsa.apple.com iframe on icloud.com). They've rejected it for different reasons, but the important thing here is that they've rejected it:

• Chrome would've always rejected these cookies because they treat unspecified-SameSite as "Lax" by default, which means they would've rejected the attempt to set these cookies in the first place for the same reason that we're currently rejecting them in (5) above.
• Safari would've always rejected these cookies because Safari always considered them to be third-party cookies (since they're set in a third-party iframe).
  Since idmsa.apple.com seems to be permissive when this cookie is omitted from requests, Chrome & Safari's cookie-rejections happen to mean they don't have any "stale" versions of this cookie saved, and so they avoid this issue.

Anyway. Based on a discussion with Apple folks today, they're going to attempt to roll back the SameSite=Lax change, which should mean Firefox users will accept new/fresh values of the cookie again and will be able to authenticate using those new/fresh values.

Comment 20

[Daniel Holbert [:dholbert]]

Note: if we were to be able to fix bug 1618610 (i.e. if we switch to SameSite-unspecified-means-Lax), then we think that would also avoid this issue (even in a world where Apple didn't roll back their change).

In my breakdown in comment 19: the users' "stale" cookies from (3) have SameSite, and we would start treating them as if they had SameSite=Lax, which would mean they would no longer be sent to this cross-origin idmsa iframe and they'd stop causing authentication failure.

(Maybe we would even automatically purge them at that point, because they shouldn't be allowed to have even been set, in a world where we're interpreting them as SameSite=Lax? But anyway, the important part is that we'd stop sending them.)

Comment 21

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #19)

(3) Until very recently, this idmsa aasp cookie was created with SameSite unspecified, which Firefox treats as "None". Firefox users who visited iCloud.com in the past may have such cookies stored in their cookie database.
(4) This "idmsa" identity-management service recently deployed an update which made them start specifying SameSite=Lax for this cookie instead.

This is now fixed -- Apple has reverted the change noted in (4), so this cookie is being sent with SameSite unspecified now, which makes us consider it to be acceptable in a third-party-iframe, so we can replace the stale cookie instead of being stuck with it forever.

Comment 22

[Calin Tanase]

Verified, the issue no longer reproduces.

Tested with:

• Browser / Version: Firefox 144.0-candidate build 1
• Operating System: Windows 10