Fix/Clarify approach to setting token limits

src/content/docs/build/tokens/configure-tokens.mdx

@@ -16,15 +16,16 @@ Tokens are an essential part of keeping your application secure. They enable the
 
 Tokens need to be updated and refreshed to remain secure, which is why you need to set how long a token lasts, for each token type.
 
-## Define the lifetimes
+## Defining token lifetimes
 
-You can define the lifetime (expiry time) of ID tokens, access tokens, and refresh tokens.
+You can define the lifetime (expiry time) of ID tokens, access tokens, refresh tokens, and SSO session expiry tokens. Expiry and timeouts are usually defined in seconds - where 3,600 seconds is one hour and 86,400 seconds is one day. Tokens and sessions need to be configured per application.
 
-Authenticated sessions can also be time limited. For example, you can define how long a session lasts without user activity. This is also called the session inactivity timeout.
+- **ID Tokens**: Contain identity information about a user. These do not need to last long as identity info is only needed at the moment of authentication, and is unrelated to session lifetimes.
+- **Access tokens**: Contain access permissions for a user during authentication. These are the most vulnerable token for attacks, and we do not recommend extending the access token lifetime beyond 1 day.
+- **Refresh tokens**: Are issued at the same time as an access token, and extend a user's session without them having to reauthenticate. If you want a user to stay authenticated without having to sign in daily or more frequently - set a high lifetime for refresh tokens.
+- **Session inactivity timeout**: A user can be requested to re-authenticate if they do not sustain activity in the current session. We recommend setting a fairly short limit  for inactivity - e.g. up to one day. If you extend the session inactivity timeout a user's data may become vulnerable, for example if they sig in on a public device and forget to sign out. 
 
-Expiry and timeouts are usually defined in seconds - where 3,600 seconds is one hour and 86,400 seconds is one day.
-
-Tokens and sessions need to be configured per application.
+Token and session expiry should be approached with priority for system and user security. The aim is to reduce the risk to user data if sessions are sustained via vulnerable tokens (like access tokens), or there are high limits for session inactivity.
 
 ## **Set token lifetimes**