According to the specification of Bittorrent tracker (https://wiki.theory.org/BitTorrentSpecification) peer is identified by their peer_id and ip. peer_id is passed to tracker in announce request, ip - from request headers, but optionally can be passed as a query parameter. How tracker knows that this request was actually sent from this peer (not a fraud) without any key?
Note that the official specification lists that parameter as optional, meaning that it is not part of the identity of the client. Rather it should be considered as a hint to the tracker that the tracker should hand out that IP to other clients instead of the source of the announce connection. This hint should be ignored if the tracker doesn't trust the client.
Trust can be established if a client authenticates itself to the tracker (e.g. via HTTP basic auth or a secret token in the announce URL).
Instead of trusting the client the tracker could also verify it, e.g. by opening a bittorrent connect to the IP and port that was announced and then send a bittorrent handshake for the infohash that was announced to check if the remote can accept bittorrent connections. That also has the advantage of rejecting announces that aren't reachable due to firewalls or NAT limitations.
For open, public trackers neither approach is practical, so they usually ignore the &ip=... parameter. Trackers deployed in more restricted environments do make use of the trust and/or verify approaches.