Revoke authenification

sanderendas

We have been very impressed by the Xano system and community. We're running into a small question we can't seem to find the best answer for.

Our proof of concept uses the authentication token to validate interactions between frontend (postman for now) and the backend. All is great and happy.

Now we're running into the situation that we have a logged in user communicating with secure endpoints using the authentication token. How would we revoke that users access to the API is het get's fired from his job. Waiting for the authentication token to expire leave quite a big gap in security. Running a check on all api endpoint via custom function to check if the user login is still valid adds overhead.

How would you deal with a challange like this?

Bas van Ginkel

To elaborate a bit. We have seen answers that said to limit the token expiration time, but this also introduces undesirable behaviour as it could cause users to logout to soon.

MattLaro

Do you have a user table of some sort? A "quick" solution would be to introduce a "is_locked" flag field in your table.

Then, create a function that returns nothing and query the user table to retrieve the is_locked flag. At the end, inside this same function, check, with a precondition, if the flag is not true (just in case your flag could be empty instead of false). If it fails the precondition, return a similar response as if the token is an invalid token.

You could then use this in the auth me and auth login endpoints at the beginning of the call.

That way, even if the token stays valid, as soon as this "is_locked" flag is check, the user will be unauthorized to be logged in.

For max security though, it would require you to update ALL endpoints that usually requires authentication with the function at the very beginning of the call so the user cannot do any actions when still logged in.

The downside is the time spent to updating those functions and the extra step that could potentially leak security if forgotten in an authenticated endpoint, the slight increase in processing time (because of the query).

There's probably better ideas though 😁 I just gave one.

Bonus: This function will be expandable if you need to check other things regarding access of your user to the app. You change it there and it changes it everywhere!

MattLaro

I just read your comment in the end about "Running a check on all api endpoint via custom function to check if the user login is still valid adds overhead."

It's true, of course, but the whole point of a Token is only to verify the validity and authenticity. Once the authentication is verified, it is valid for it's life span and as long as the user has that token.

If you state "Well yes, I recognize this user, but we don't want it to fiddle in our data anymore", you will need an Authorization logic as well.

Ray Deck

Classically this calls for a refresh token pattern. You have your access token that is short-lived (maybe an hour?). You use the built-in Xano auth token for this job. You have a second token that is long-lived (e.g. on your user table or another table of refresh tokens) that has the job of redeeming auth tokens. That way when the user is fired (or the computer is compromised and you just want to remove the tokens, even if not the person) you can do so without a lot of ceremony in the various services. The access token is too old, so the front-end uses the refresh token to ask for a new one. The back-end says "that's no good" and kicks you back to the login screen.

This is how the long-lived services you know and love today - like gmail, outlook, etc - all work. Logging in gives you the short-lived access token and the long-lived refresh token. The latter is easier to invalidate, while the former is nice and fast.

sanderendas

That is an interresting option. So how would i create the follow up refresh token, after the session token is expired? At the top of every authenticated API call i see the lock icon. The token checkup of my token appears 'in there' (wich is nice because i would like to have all my auth logic in the a prevent overhead on each api). What (or where) would be the best way to handle the refresh token logic?

Ray Deck

I would make an endpoint that returns a new access token when given a refresh token. And the front-end would be responsible for managing the hygiene of noticing that their access token is aging or expired and getting the new one. That's how MSFT and Google do it.