Creating a bearer token on the server side

[crimson moth]

I'm using an alternative table/collection of users, independent of Directus users. The frontend interacts with these users data via custom extensions.

Currently all functions are authenticated via a bearer token that's sent to the custom extensions via:

` const bearer_token = 'tokenstring';

    const options = {
        method: 'POST',
        cache: 'no-cache',
        headers: {
            'Accept': 'application/json, text/plain, */*',
            'Content-Type': 'application/json',
            'Authorization': Bearer ${bearer_token}
        },
        body: JSON.stringify(postdata)
    }

            let url = "https://serveraddress/customextension/:request
    fetch(url, options) ...`

bearer_token is generated from a Directus user and so, the custom extensions are acting as that Directus user.

The problem

The bearer_token being used is available to inspect in the front end source code.

My question

Can I declare the token in the custom extension?

I can only find the js standard of using it in Authorization, but if I can use it in my custom extension code, I can keep it discreet.

[gilded cradle]

you can add a custom token to a user 👀

if you do that, the token will be fixed until you remove/update it

[crimson moth]

Can you elaborate a little bit? I'm not sure I fully understand the implications or method.

As I understand it, I need to perform database tasks through a Directus user if not using the public role.

If I create a custom token for the Directus user rather than the current bearer token, isn't this still another token that can be inspected and used by others to manipulate the db?

[gilded cradle]

yes

thats true

can you elaborate what you want to do inside of the extensions?

because most of the time either accountability can be used

or some other way to get the current active token of a user

[crimson moth]

Essentially I'm using a custom authentication for my own users collection. I still rely on Directus users for the internal staff roles and admin. The custom collection of users is for our customers.

Customers can log in via a separate front end and I use custom tokens stored in local cookies to authenticate the customers logins against the custom users collection.

Behind all of this, the Directus API is being used and, as I didn't want to expose all db to a public role, the frontend is authenticating via a bearer token (of a Directus user with admin access), per the original question and example.

I am only using this bearer token authentication during development.
I want to be able to perform admin actions on the Directus db without exposing tokens.

I'm wondering if my best solution is to continue as I am, but limit IP access for that user only to the server of the frontend. Is this considered secure enough to prevent others manipulating the db while having access to a Directus user token?

The Directus User, by the way, is arbitrary. In this case I have one called 'System' that I can recognise as having performed an action requested by the frontend app, rather than manually by any of the staff internally, who have their own Directus User accounts.

By 'limiting IP access for that user' I meant limiting IP access for that user role.
I could create a new role that had the permissions needed for the frontend, generate a token for it, let the frontend use this token and limit IP access to the server IP of the frontend.

[gilded cradle]

One thing that i would like to ask, why a custom users collection?

and im not sure if a fixed token is a good solution for dev, most of the time you have a session of 7 days when you login

[crimson moth]

Mostly, and originally, it was convenience of migrating an existing model (existing table was parented to various others already).

Secondly, Directus own users implementation felt quite orientated towards small to mid size teams in the UI. It felt cumbersome to manage potentially thousands of users (there's no list view for users as standard).

From seeing this, I wasn't sure what was happening in the background for the built-in users table that it wouldn't be slower to process requests than with than a regular custom table that's not as integrated. Obviously, this could be completely naiivity on my part.

[errant sleet]

Directus internal user & roles system can and does handle thousands of users easily, so I wouldn’t rule that out, and then you have the built in tokens and permissions going on which means less work on your end to figure out things like this.

If connecting an existing table then you can set up a relationship between the directus_users collection and the existing collection.

[gilded cradle]

True! In the end its just a collection like the others, you can find it at the bottom of your data model -> system collections

[errant sleet]

Yup, and pretty common to do an “account” or “profile” or other collection that’s associated with the “directus_user” collection and from there does the actual linking to other collections.

Also using the built in roles & permissions means better security such as setting inside a role that records can only be viewed by the $CURRENT_USER for a collection for example

[crimson moth]

Good to know, thanks to both of you.

To clarify: would I be right in believing there would be little difference in performance from using my own collection of users with several thouand users vs directus_users built in user roles table for the same numbers?

If so, it would be worth my while making this change to make token issues, such as this, easier to manage

[errant sleet]

You’d probably find improvements using the built in over custom since you’re not re-inventing the wheel as it were. So yes it would be worth your time