So in fact, this is an SSO (single sign-on) system, right?

Yes.

Can't XMPP sender addresses be forged, just like email addresses?

The XMPP protocol has security features that make it impossible (well, nothing is impossible, but much harder anyway) to fake the sender domain name of stanzas (the name after the '@'). See the corresponding section of RFC 3920 (XMPP Core) for more details.

What about the username (before the '@')? Well, it's up to your server to check that the 'from' is not faked. This also means that if your XMPP server gets hacked or if the administrator is evil, it is possible to send messages on your behalf, but hey, the problem is not new: they could also change your account password, sniff it, close your account... If you don't trust your service provider, there is already a problem. Use another one or run your own server.

Note that if you managed to send a ticket with a fake 'from' address despite all, it would only create a ticket associated to that address for a short time and send it to the faked address (not to you), so you would still have to find out its value.

Why is there no need to provide the JID with the ticket?

There are two reasons why authentication schemes usually need a username (here, the JID) along with the password (here, the ticket):

  1. Several users can choose the same password, so sending the username during the authentication phase disambiguates the whole credentials.
  2. On large user bases, it prevents an attacker from sending a random password hoping that it will match an existing one, since the attacker would also have to send the corresponding username.

With DIAS, on another hand, it is possible to generate unique tickets. In that case, the ticket is sufficient for the server to identify the user behind it. Moreover, the ticket expires after a determined duration or after it has been used once. Provided the generated tickets are long enough and the time-to-live is short enough, this prevents an attacker to guess a ticket by sending a random value.