The ability to send a message with integrity verified via an existing security context is the access to a cached establishment of credentials. With each new message successfully unwrapped it is fine to associate data like the source principle from the context that unwrapped it by using gss_inquire_context().
If the client does not either request a new context or send a message unwrappable with an existing context then nothing with integrity is being received so the server should be ignoring the client. (But the server could be using cached credentials on behalf of the client for ongoing tasks if the underlying mechanism and configuration support delegation.)
A standard to organize relationship lookup between channels and security contexts is not part of GSS; it only provides an optional means to verify the channel matches in case alteration is relevant to your application.
So, you normally have a unique but insecure channel that is associated by either side with its security context. That could always be emulated and more transient by having the server send an opaque reference back to the client. The client then sends this along with each wrapped request to replace the server side app's need for mapping with new issues like safe bounds checking in a pool.
I would discourage you from building a solution to approving authentication longer than the system is willing to issue you a security context. Normally, creating new security contexts has no impact on the human user unless that is part of the system policy or they are using an underlying mechanism that lacks a TGT-like mechanism..
