diff --git a/aspnetcore/security/authentication/identity-api-authorization.md b/aspnetcore/security/authentication/identity-api-authorization.md
index 75551c53e7a5..389cfc1c9eac 100644
--- a/aspnetcore/security/authentication/identity-api-authorization.md
+++ b/aspnetcore/security/authentication/identity-api-authorization.md
@@ -204,7 +204,7 @@ Some web clients might not include cookies in the header by default:
 
 We recommend using cookies in browser-based applications, because, by default, the browser automatically handles them without exposing them to JavaScript.
 
-A custom token (one that is proprietary to the ASP.NET Core identity platform) is issued that can be used to authenticate subsequent requests. The token is passed in the `Authorization` header as a bearer token. A refresh token is also provided. This token allows the application to request a new token when the old one expires without forcing the user to log in again.
+A custom token (one that is proprietary to the ASP.NET Core identity platform) is issued that can be used to authenticate subsequent requests. The short-lived access token is passed in the `Authorization` header as a bearer token. A longer-lived refresh token is also provided. This refresh token allows the application to request a new access token when the old one expires without forcing the user to log in again.
 
 The tokens aren't standard JSON Web Tokens (JWTs). The use of custom tokens is intentional, as the built-in Identity API is meant primarily for simple scenarios. The token option isn't intended to be a full-featured identity service provider or token server, but instead an alternative to the cookie option for clients that can't use cookies.
 
@@ -226,6 +226,14 @@ public signOut() {
     responseType: 'text'
 ```
 
+## SignOut everywhere
+
+Apps need to react to events involving security sensitive actions like changed password, or other security sensitive events.  This is achieved using the [security stamp](/dotnet/api/microsoft.aspnetcore.identity.identityuser-1.securitystamp) feature of Identity.
+
+How often the security stamp is validated is configured using [SecurityStampValidatorOptions.ValidationInterval](/dotnet/api/microsoft.aspnetcore.identity.securitystampvalidatoroptions.validationinterval) for cookie-based authentication, or [BearerTokenOptions.BearerTokenExpiration](/dotnet/api/microsoft.aspnetcore.authentication.bearertoken.bearertokenoptions.bearertokenexpiration) for token-based authentication.
+
+The validation interval is a balance between immediate session invalidation and database performance. A shorter interval requires more frequent database hits, while a longer one leaves a small window where an old, potentially compromised session might remain active. 
+
 ## The `MapIdentityApi<TUser>` endpoints
 
 The call to `MapIdentityApi<TUser>` adds the following endpoints to the app:
@@ -309,6 +317,8 @@ If `useCookies` is `false` or omitted, token-based authentication is enabled. Th
 
 For more information about these properties, see <xref:Microsoft.AspNetCore.Authentication.BearerToken.AccessTokenResponse>.
 
+Use the [BearerTokenOptions.BearerTokenExpiration](/dotnet/api/microsoft.aspnetcore.authentication.bearertoken.bearertokenoptions.bearertokenexpiration) property to set how long the access token will remain valid for.
+
 Put the access token in a header to make authenticated requests, as shown in the following example
 
 ```http
@@ -340,6 +350,8 @@ If the call is successful, the response body is a new <xref:Microsoft.AspNetCore
 }
 ```
 
+Use the [BearerTokenOptions.RefreshTokenExpiration](/dotnet/api/microsoft.aspnetcore.authentication.bearertoken.bearertokenoptions.refreshtokenexpiration) property to set how long the refresh token will remain valid for.
+
 ## Use the `GET /confirmEmail` endpoint
 
 If Identity is set up for email confirmation, a successful call to the `/register` endpoint sends an email that contains a link to the `/confirmEmail` endpoint. The link contains the following query string parameters: