19 lines
1.3 KiB
Text
19 lines
1.3 KiB
Text
|
|
||
|
|
=== 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.
|
||
|
|
|