3 ms·

Thank you very much. The guide is very helpful! If you deploy the auth handling as a microservice, how do you sync state between the auth-service and the resso

Thank you very much. The guide is very helpful! If you deploy the auth handling as a microservice, how do you sync state between the auth-service and the ressource-service. (For example if the token is revoked). Do you use web hooks? In that case, what addional implementation would I need to add If I want to assure consistency/ implement transactions? Do you have any axperience in that field. Edit: I just realized that revoking could be done simply by changing the signing key, but that would revoke all JWTs...

ecesena 6y ago
This is where my opinion may slightly differ from the blog posts you cited. Keep in mind that my experience is more consumer-like vs e.g. a financial institution, so requirements may be different based on your application. The main question is: assuming you detect a weird case, are you going to conservatively log out the user or risk that an attacker might be taking over the account? I'm for the latter, of course under the assumption that auth is not your last line of defense, but you'll monitor the user/attacker activity and block the account if you think it's an attack. If I were to build a financial app, I'd definitely opt for the former. My other assumption/experience is that storage is cheap, so you should store (a reference to) all valid tokens. Revoke is then done by marking the record as revoked and/or delete the record. Now, when the resource service receives an authenticated call, you can either: 1. Check the token against the "list of all tokens" storage (likely exposed by the auth service). Or, 2. Trust that the token hasn't been revoked before expiration. One way you can achieve 2) is for example to have your frontend to periodically pull the auth service and either receive a refreshed token, or get the cookie cleared out.

3 ms·

Thank you very much. The guide is very helpful! If you deploy the auth handling as a microservice, how do you sync state between the auth-service and the resso

by Draken93 6y ago

ecesena 6y ago
This is where my opinion may slightly differ from the blog posts you cited. Keep in mind that my experience is more consumer-like vs e.g. a financial institution, so requirements may be different based on your application. The main question is: assuming you detect a weird case, are you going to conservatively log out the user or risk that an attacker might be taking over the account? I'm for the latter, of course under the assumption that auth is not your last line of defense, but you'll monitor the user/attacker activity and block the account if you think it's an attack. If I were to build a financial app, I'd definitely opt for the former. My other assumption/experience is that storage is cheap, so you should store (a reference to) all valid tokens. Revoke is then done by marking the record as revoked and/or delete the record. Now, when the resource service receives an authenticated call, you can either: 1. Check the token against the "list of all tokens" storage (likely exposed by the auth service). Or, 2. Trust that the token hasn't been revoked before expiration. One way you can achieve 2) is for example to have your frontend to periodically pull the auth service and either receive a refreshed token, or get the cookie cleared out.