After doing some research and finding discovering other issues from Auth0, I have a sample solution for the matter in hand. This is a poc but, I do not see any other solution than this. Still there will limitations in highly-traffic env since I call Auth0 management api. Also please understand that I am having a SPA+Api and I use silent authentication so if the user is logged in, will be logout after a few acces_token refreshals. The acces_token is 10-15 minute.
- I have discovered that when a user is disabled in Gsuite/O365, the refresh tokens that were generated for the account will be revoked i.e(some set the expiration date timestamp, others delete or whitelist the token).
- For getting refresh tokens from Gsuite/O365, you will have state in the client app, that you want offline_acces. This may pose a downside, but right now the app is for internal use so I can accept it.
- I created a rule and there I check if the refresh token is valid. This is more difficult than it seems, because the result of the token was received after the webtask finished i.e the client does not know anything about the refresh token. So the first compromise was made, I will store a flag in the user_metadata, logout and set it to true. The next time the app requests an acces_token via silent authentication the checkup for the flag will throw an error and the app will logout on the client side, hence the logout flag is set to false.
Right now, this is the only solution that I have for an app that has requirements for having SSO. Another solution would be, to shorten the cookie lifetime on the Auth0 tenant, and force a login every x ammount of time. Due to app requirements that solution was not option, still that is a secure way of doing things.