The authentication tag is defined as an output parameter in GCM (see section 7, step 7 of NIST SP 800-38D). In all the API's I've encountered it's appended to the ciphertext. Where it is actually placed is up to the protocol designer. The protocol designer may well consider the place behind the ciphertext as ad hoc default though. The name "tag" of course kind of indicates that it should be tagged to the ciphertext and that may well mean direct concatenation.
The tag is often considered part of the ciphertext within an API. This means that the API is less flexible, and that it requires the buffering of the ciphertext (up to the size of the tag value) as the decryption routine otherwise doesn't know where the ciphertext ends and the authentication tag starts. This means in turn that the online property of the counter mode encryption is damaged.
So in generally it is better to treat the authentication tag as separate parameter as API designer, and leave the location of the authentication tag up to the protocol designer. The protocol designer may well choose to prefix the ciphertext with a length component, which would render the buffering unnecessary.
In your case it doesn't help to directly look at the GCM specification, you need the protocol or API specifications. I would suggest to look for it at the end of the ciphertext if the location hasn't been strictly defined. The tag size should be a valid, predefined parameter value.
In RFC 5116: An Interface and Algorithms for Authenticated Encryption the authentication tag is explicitly placed at the end of the ciphertext for GCM mode encryption. This is due to the following requirement in section 2.1:
There is a single output:
- A ciphertext C, which is at least as long as the plaintext or
- an indication that the requested encryption operation could not be performed.
and further explained by section 5.1:
AEAD_AES_128_GCM ciphertext is formed by
appending the authentication tag provided as an output to the GCM
encryption operation to the ciphertext that is output by that
This RFC is - for instance - used by the TLS specifications. Note that the size of the ciphertext is made explicit in those specifications, which means it should be easy to separate the tag from the actual ciphertext.