21 lines
1.6 KiB
Text
21 lines
1.6 KiB
Text
|
|
=== 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.
|
|
|