keycloak-scim/server_admin/topics/threat/compromised-tokens.adoc


=== Compromised Access and Refresh tokens

There are 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 refresh 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. Pushing new not-before policy will also ensure that application will be forced to download
new public keys from {{book.project.name}}, hence it is also useful for the case, when you think that realm signing key was compromised.
More info in the  <<fake/../../realms/keys.adoc#_realm_keys, keys chapter>>.

You can also disable specific applications, clients, and users if you feel that any one of those entities is completely compromised.
threat 2016-05-31 22:00:59 +00:00
			`=== Compromised Access and Refresh tokens`

Minor changes for threat model chapter. 2016-06-07 19:02:18 +00:00			`There are a few things you can do to mitigate access tokens and refresh tokens from being stolen.`
threat 2016-05-31 22:00:59 +00:00			`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.`
Replace referesh by refresh 2016-06-01 13:15:13 +00:00			`If an admin detects a leak, they can logout all user sessions to invalidate these refresh tokens or set up a revocation policy.`
threat 2016-05-31 22:00:59 +00:00			`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.`
KEYCLOAK-3823 Docs about pushing not-before will invalidate realm keys 2016-12-01 16:45:28 +00:00			`This will enforce that any tokens issued prior to that date are now invalid. Pushing new not-before policy will also ensure that application will be forced to download`
			`new public keys from {{book.project.name}}, hence it is also useful for the case, when you think that realm signing key was compromised.`
			`More info in the <<fake/../../realms/keys.adoc#_realm_keys, keys chapter>>.`

threat 2016-05-31 22:00:59 +00:00			`You can also disable specific applications, clients, and users if you feel that any one of those entities is completely compromised.`