General questions: Logout / sessions / current complexity of the features

Original message was deleted

FFO•2/23/23, 7:53 AM

1) Wouldn't it be more efficient to store Zitadel's tokens and sessions in a memory-based database like Redis, particularly for critical applications that need to verify token validity? For example, could Zitadel store revoked tokens in Redis until they expire, and provide an endpoint to check token validity by checking their exiting in redis? I don't think it is a good idea to check couchdb for each request.
a) When a token is revoked it is saved in Redis until it expires
b) A critical app that needs to verify the token uses the endpoint and Zitadel checks if the token exists in Redis.

We use cockroachDB for this since we want to globally replicate this information. So far perfomance has not been an issue on this end since our datamodel with event sourcing has some nice benefits.

You can verify a token when sending it to /userinfo or /introspect.

However ZITADEL does not store the signed token but instead it links the token to a session.

FFO•2/23/23, 7:57 AM

2) How does Zitadel manage the storage of sessions and tokens in the database? Are they cleaned periodically or directly after token expiration?

Since we use event sourcing each event is persistent into our database. But we garbage collect some information like authorization request after a while.

Sessions are stored as events and expiry based on their config (but will not be deleted)

FFO•2/23/23, 7:58 AM

3) Is it possible for Zitadel to provide information on all user sessions, including details on the device used for login (e.g. browser, mobile device), locations?

The data is there but we do not yet provide a nice GUI for this. But you can get all infos from our event api https://zitadel.com/docs/guides/integrate/event-api

ZITADEL Docs

ZITADEL leverages the power of eventsourcing, meaning every action and change within the system generates a corresponding event that is stored in the database.

FFO•2/23/23, 7:58 AM

4) Can users log out of a device, thereby closing the session and revoking all tokens generated from that session?

Yes, but currently we keep refresh tokens alive. https://zitadel.com/docs/guides/integrate/logout

ZITADEL Docs

This guide shows you the different concepts and use cases of the logout process and how to use it in ZITADEL.

FFO•2/23/23, 7:59 AM

5) Is it possible to integrate email and SMS with event actions feature, thereby reducing the overall complexity. By incorporating this feature, users can choose to send either an email or SMS, or define a JavaScript function for each action. Furthermore, I think the ability to define native plugins for customizing email and SMS providers will make it easier to connect to other system. This enhancement will improve the user experience and make the system more efficient in handling event actions. For example, Logto provides the ability to customise sms and email connectors

Yes thats something we want to open up for such cases

FFO•2/23/23, 8:00 AM

6) In the documentation on GitHub, there is a distinction made between the backend and the login module located in "./internal/api/ui/login." Would it be better to separate these components onto different servers to enable better customization?

Yes we want to seperate the whole login into a nextjs app, work will start somewhere in h1/23

FFO•2/23/23, 8:42 AM

Sorry for asking but for the event API how can I get the sessions and the device info and log in location is this info really available which event store this info?£

I was quickly checking myself and it came to my mind that we still hide information that are present in the authorization flow.

But this is subject to be changed

we btw. just released our access API which allows you to log all http request with their metadata (the API should follow soon)

As for the logout, Why are refresh tokens are kept alive I think they should also be revoked. After all, if a session generated a refresh token, it seems risky to allow it to be used to obtain a new access token after the session was closed.

Well logout is not exactly an easy process because you need to choose weither you want to logout all apps from one useragent or only one and if so also all tokens.
@livio please correct me if I am wrong but I am to 80% sure that we do not revoke refresh tokens on SLO, right?

FFO•2/23/23, 6:24 PM

@Amine we are open to suggestion btw. we just wanted to give full transparency