Request: Directus 10.10 Session Based Authentication

[Dominic-Marcelino]

Directus 10.10 introduced a new authentication mode "session" which stores a session token as cookie. This makes a bunch of things a bit easier, as multi-tabs logins are handled by default and assets can be requested without a token in the query. What do you think of adding this as an option to the module so that it relies on the sdk for that part too?

Haven't checked the possibilities in details, and how it works with nuxt yet, but would like to hear you thoughts about it 🎉

More information: https://github.com/directus/directus/pull/21239

[BlackDahlia313]

I was wondering if any changes would need to happen before I updated. Holding off.

[becem-gharbi]

I have few notes on adding this feature.

• The original reason behind it is to avoid passing token on query params. So it's a security first decision.
• Should it be the default mode for authentication? given it is for SSO.
• The session token cannot be refreshed after expiration. Should it be refreshed on page load/reload?
• Regarding QraphQL, the module uses Apollo client which accepts websockets authorization via connectionParams. We will need cookie-based (httpOnly) alternative solution.

[Dominic-Marcelino]

Should it be the default mode for authentication? given it is for SSO.

On the one hand I tend to align with the sdk for defaults on the other hand this module is way more specific implementation. As I think the session-based approach would be the best and most secure for most use-cases I tend setting it as default.

The session token cannot be refreshed after expiration. Should it be refreshed on page load/reload?

Not 100% sure, bot don't we still get the expiration returned? This way a refresh could be scheduled before it expires (e.g when there's only 10% of the time left)

---

@br41nslug Sorry for ping, but as the initial author you maybe could give some insights about this?

---

Note: This also related to #49

[br41nslug]

Not 100% sure, bot don't we still get the expiration returned? This way a refresh could be scheduled before it expires (e.g when there's only 10% of the time left)

Correct, same logic holds for both cookie and session mode, the SDK authentication composable attempts to refresh the token X milliseconds before expiration (default is 30 seconds but is configurable)