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 {project_name} and its clients and applications. It might seem obvious, but since {project_name} does not have SSL enabled by default, an administrator might not realize that it is necessary.

Another thing you can do to mitigate leaked access tokens is to shorten their lifespans.  You can specify this within the <<_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 {project_name}, hence it is also useful for the case, when you think that realm signing key was compromised.
More info in the  <<_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
fixed RHSSO-876 2017-03-15 17:35:07 +00:00			`=== Compromised Access and Refresh Tokens`
threat 2016-05-31 22:00:59 +00:00
Convert documentation to AsciiDoctor 2017-08-28 12:50:14 +00:00			`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 {project_name} and its clients and applications. It might seem obvious, but since {project_name} does not have SSL enabled by default, an administrator might not realize that it is necessary.`
threat 2016-05-31 22:00:59 +00:00
Convert documentation to AsciiDoctor 2017-08-28 12:50:14 +00:00			`Another thing you can do to mitigate leaked access tokens is to shorten their lifespans. You can specify this within the <<_timeouts, timeouts page>>.`
fixed RHSSO-876 2017-03-15 17:35:07 +00:00			`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.`
threat 2016-05-31 22:00:59 +00:00
Convert documentation to AsciiDoctor 2017-08-28 12:50:14 +00:00			`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 {project_name}, hence it is also useful for the case, when you think that realm signing key was compromised.`
			`More info in the <<_realm_keys, keys chapter>>.`
KEYCLOAK-3823 Docs about pushing not-before will invalidate realm keys 2016-12-01 16:45:28 +00:00
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.`