Hi all,

We are working on supporting JWT revocation for synapse gateway. Please
note that the default token format for 3.0 synapse gateway is JWT.

Please find the discussed design for this feature.

[image: JWT.jpg]

In summary, we will be storing the revoked token signatures against the
expiry timestamp(timestamp is needed for cleanup) in AM_DB and these
entries will be fetched to the gateway during the startup via a web app
deployed in KM. This is similar to how we fetch key templates and blocking
conditions during the startup via the throttle web app.

When a token is being revoked after startup, an event will be put into a
JMS topic or multiple JMS topics depending on how the gateways are
subscribed to the topic(via JMS event publishers). When the JMS listener
fetches this event, it will clear the gateway cache entry related to the
token and also populate the in-memory revoke map.

When a request is received to the gateway, it will be first validated
against the cache and only if it is not in the cache the signature will be
validated against the revoke map. We have decided not to validate against
the invalid cache for this flow because the revoke map will anyway have all
the invalid entries whereas the invalid cache will not always have all the
entries.

Both the database table and revoke map has the expiry timestamp stored in
them to facilitate the cleanup process of expired revoked tokens. We are
planning to clean both the database table and the revoke map via a timer
task with a suitable interval to ensure they will not be growing
continuously.

Please let me know your suggestions.
-- 
Thanks & Regards,

*Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc
Mobile : +94772338839 | fazl...@wso2.com
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to