You're correct here, and you just need to use the ID extractor, and make the TTL as long as your re-auth period.
The Tyk SessionObject can be used to store long-term state in the meta data fields, since Tyk will "expire" tokens, but the Session data persists (difference between not allowed/expired and not found/evicted). For example, if you generate a token in Tyk and then need to have a reference to the actual user ID of the user etc. This token has a lifetime of 1 week. After 1 week, you may want to extend the validity of the key (this happens more often than you think, for example when people bake a token into an application). So Tyk stores all this data long-term, and expiry is not the same as a cache eviction. So, in Tyk a SessionObject can track long-term state.
The ID extractor will not do this, it evidcts the cached entry, so any meta data or addiitonal information that is being tracked alongside this user is not persisted beyond the lifetime of the cached object. You need to do it yourself, in your case, the data is in ldap and managed elsewhere (so you do not need this at all), but in other cases where the request is validated with e.g. SAML or some other system, then you may want to persist long-term state in some way. In a custom auth plugin, you need to do this yourself.
When you asked about the GetKeyData and SetKeyData functions, that's what they are for, they are there to either forward-populate a Tyk-managed SessionObject and Key (as in you can manage it via the dashboard), or to do token exchange (inbound token is x, generate token y, use token y for the remainder of the request through header substitution etc.)
The bottom line in: Just use the ID extractor, everything else is a distraction.