A bearer token/JWT/SAML assertion/other artifact used in an SSO system represents a verified, verifiable, authoritative claim of right of a specific user, with temporary duration. JWT have an expiry time (e.g.
expires_in = 3600 seconds), whereas a SAML assertion has an expiry time stamp (e.g.
Not on or after = 2017-06-20 11:38:01).
Aside from that, everything is very general. The claim of right could be anything-- membership in a role, access to a resource, etc.
Two general approaches
There are two ways I have seen this sort of mechanism used in an authentication context:
1. The assertion/token/artifact represents the right to access a system.
In this case, the auth server's token essentially has a long-ish duration (say, 20-40 minutes), and acts as a multi-domain session cookie. When it is close to expiration, you'd have to go back to the auth server to get it "refreshed" or "renewed," and you may end up getting a brand new token as a result.
In some systems, the refresh operation requires a round trip to the auth server in the browser itself. In others, it can be accomplished via web service on the back end. The latter is less "pure" of an implementation (ideally, only the auth server should be able to give out tokens) but in certain circumstances it is necessary to keep things cleaner for the end user-- it can be very disruptive to take the browser somewhere else, even temporarily.
2. The token represents the right to initiate access to a system
In this case, the auth server issues a token of relatively short duration (say, 60 seconds), and the domain server uses this token as sort of a password in its own session management mechanism. The domain server would then issue its own session cookie, and the auth server's token would no longer be needed. The domain server would be responsible for refreshing any session cookies itself, which is usually very trivial because that sort of thing is built into web platforms, e.g. ASP.NET forms authentication.
The down side of this approach is that it is not quite a true SSO... you cannot seamlessly navigate from domain to domain without going back to the auth server to get a new token to initiate a new domain-specific session. But the up side is that it is much simpler to implement.
So... do you need to refresh?
Yes, but depending on the way you have things architected, you might be refreshing the token issued by the auth server, or you may be refreshing a token that the domain server owns, the latter of which is trivial.