Another interesting aspect of this is that it can be useful in IoT.
In IoT the devices themselves are often pretty dumb, they have small amount of storage and don't even talk http. The hub they connect to is generally more beefy and talks both zigbee (or whatever) and http. With IoT devices it would work something like:
1. User registers a new IoT device through some sort of flow (click a button on the hub, through an app on the smartphone, through the web browser on the hub portal, or whatever)
2. The hub creates a new "device" account for it in Keycloak, and also gets tokens from KC (refresh or offline whatever). It stores the refresh/offline token permanently, but access token only in memory
3. The hub also creates a short token (token UUID, or key/secret pari, whatever)
4. The hub sends the small short token to the device
5. The device now only needs to store this short token and also only send this short token
6. The hub looks up the real token based on the uuid or key/secret pair, and swaps it in any outgoing request
Benefits here is that a small IoT device can communicate to a REST service secured with bearer tokens without having to deal with large bearer tokens, refreshing the token, etc..