=== Compromised Access and Refresh tokens

There's a few things you can do to mitigate access tokens and refresh tokens from being stolen.
The most important thing is to enforce SSL/HTTPS communication between {{book.project.name}} and its clients and applications.
This might seem like a no-brainer, but since {{book.project.name}} does not have SSL enabled by default, many naive admins
might not realize they have to do this.

Another thing you can do to mitigate leaked access tokens is to shorten their lifespans.  You can specify this
within the <<fake/../../sessions/timeouts.adoc#_timeouts, timeouts page>>.
Short lifespans (minutes) for access tokens for clients and applications to refresh their access tokens after a short amount of time.
If an admin detects a leak, they can logout all user sessions to invalidate these referesh tokens or set up a revocation policy.
Making sure refresh tokens always stay private to the client and are never transmitted ever is very important as well.

If an access token or refresh token is compromised, the first thing you should do is go to the admin console and push a not-before revocation policy to all applications.
This will enforce that any tokens issued prior to that date are now invalid.
You can also disable specific applications, clients, and users if you feel that any one of those entities is completely compromised.