REST-API: Support reusing authentication from configured auth provider

[paderick]

Summary

Directus supports external authentication providers.

The REST-API from Directus requires a login via authentication flow (same flow which is used for login in Admin Panel).

Clients which have not the option to use a web-frontend for authentication or which already have a valid session from the external authentication provider needs right now a separate session from Directus to access the REST-API.

It would be helpful when the access token from the user session (which comes from the external IdP) could be used as Bearer token in Authorization header to accessing the REST-API from Directus.

Basic Example

Having a client application which already have an active and valid user session, e.g. from Keycloak. This application should now send data to Directus (which will be used as data hub in this constellation) and request data which the user can access to with the current user session.

Motivation

Since Directus is a truly headless CMS, it would be helpful to use an existing session from an external identity provider for API calls to retain the user session while accessing data.

It would increase the security aspects when an existing session could be shared instead of having a second session only for the communication with Directus.

Respecting the user session will ensure that the user context will be used accessing data through the REST-API. It is not best practice to let the business logic or the API consumer handle the users data-security & -privacy.

This feature could increase the SSO featureset from Directus from "Admin-Panel SSO support" to "Fully SSO support".

More and more HomeLabs uses Keycloak or Authentik for having one shared instead of multiple user accounts. SSO is a comfort feature in this case.
While Directus is used as data hub in some constellations, this feature ensures that no static user token, which could be a security risk, are required.

Since Enterprises uses one central identity provider, SSO is a security feature in this case.
While Directus is used as data source in some constellations, this feature ensures that also other clients can be used to accessing data from Directus.

Detailed Design

All changes should be done in Directus core.

The authentication provider configuration contains already all necessary information to check and validate the given token in API requests.

The jwt contains the issuer, which could be used to identify the auth provider, which should be used to validate the token.

If the token is expired, the API should respond with a corresponding error code.

It should be checked if the user is already known.
If the user is not known and AUTH_*_ALLOW_PUBLIC_REGISTRATION is disabled, the API should respond as it do it now.
If the user is not known and AUTH_*_ALLOW_PUBLIC_REGISTRATION is enabled, the API should request the userinfo from the external IdP and creates the user account in Directus.

The token should be used to check for an existing directus_session.
If there is a valid directus_session: the token is okay and the request could be processed (with the access policies, etc.).
If there is no valid directus_session or the directus_session is already expired: A new directus_session should be created, that the request could be processed (with the access policies, etc.).

Requirements List

Must Have:

• Access token from external IdP is accepted

Should Have:

• The user should be registered, when not already existing

Could Have:

• NaN

Won't Have:

• A second authentication flow for the clients / users
• A separate (second) session for accessing user data

Drawbacks

No drawbacks identified.

Alternatives

An alternative solution is to create a custom API endpoint which transforms the session from the external IdP to a directus_session. Having such an extension not as part of the core could be a major security flaw.

Adoption Strategy

No migration needed.

This feature will significant increase the featureset of Directus and offers more comfort by having a good security standard built-in.

Unresolved Questions

The detailed design should be challenged from a directus core developer to ensure no security flaws are taken.