By `authenticating' I mean proving to Coda that I am the person who is allowed to do certain things in the file system. The Coda authentication program is `kclog'. Before you run it, you need the Kerberos tickets for a Coda user.
On its own, `kclog' or `kclog [username]' checks that your Kerberos tickets are valid, and if so, it gives you a Coda token for a limited period. With the arguments `-tofile [filename]', it also writes the token to a file, so that you can use it in disconnected mode. With the arguments `-fromfile [filename]' it reads and sets the Coda token from a file which you created earlier, without trying to verify your Kerberos credentials.
The command `ctokens' lists your Coda tokens, and the command `cunlog' destroys them.
The default time limit for Coda tokens is 25 hours. I find this uselessly short for disconnected operation, but the only way to get a longer token is to edit the source of the kauth2 daemon and recompile it. I think there should be some way to specify the lifetime of a token.
Getting a very long token, one that lasts weeks or months, is something of a security risk, as is saving it to a file. On the other hand, it is difficult to see how this can be avoided. As far as I can tell, Coda associates the user's Coda token with the Unix user ID which requested it, which is not the safest policy. It seems to me that Coda needs some idea like the Program Authentication Group (or PAG) of AFS, which lets you control this a little better.