[RFC] Possible solution for "Refresh Token setup" with current SurrealDB Authentication capabilities

[hgoona]

Hi team - the following is off the back of a lengthy discussion on SurrealDB's Auth capability and the current situation where "refreshing" of $token is not (yet) available.
Original Discord discussion: https://discord.com/channels/902568124350599239/1303884244313182238

I think I've formulated a solution that achieves the same effect as a Refresh Token, but I'd love to know what others think!

PURPOSE:

Hopefully, I've not unwittingly created some terrifying security vulnerability or hazard in the following so I'd greatly appreciate people's reviews and comments!

NOTE:

• This may have been obvious to someone more experienced in security, though it was non-obvious nor clear how to implement (at least in the first instance!) for me, despite the lengthy discussion — so perhaps this will be helpful to anyone else who is trying to achieve a similar outcome!
• As @gguillemas mentioned in the thread above and in other git issues, there is a "Refresh" functionality coming soon, but this release is TBA, and I frankly just wanted to get this Auth issue closed out so that I could carry on with developing the rest of my app with some piece of mind that my Auth is DONE! [ And hopefully done right!!😄]

SITUATION:

Setting up Authentication for an App that might be similar to a social media app,
eg:

• User logs in,
• does multiple CRUD operations,
• at sporadic intervals.
• For every CRUD operation, my client backend will validate the User (with .authenticate) prior to every request made to the sdb database.

PROBLEM:

1. $token currently has no refresh mechanism built into SurrealDB (yet), and it's recommended to keep $token duration SHORT lived. In this setting, it would force the User to "Signin" for eg. every 15mins <<< not good.
2. If I don't run the authentication (db.authenticate(token)) check for each CRUD op, I have to rely on $session being valid - even if the $token was somehow stolen, or needed to destroyed, it can't be modified/invalidated externally and will continue to Validate until session duration expires.
3. This means we can't force "Signout a User from all devices" in case of an issue - we have to wait for $session expiry
4. If we use a LONG $token duration the vulnerability is that the $token, if stolen, can be used for a long time! Not good either.
5. So we need mechanism to compensate for this, to avoid User being forced to Signin every 15mins, or forego the ability to boot out a User (attacker with Token that is stolen)

SOLUTION:

-- MECHANISM ===========================================================
-- SurrealDB $token (and $session) effectively NEVER expires (only after 10yrs)

-- #1 REFRESH TOKEN (.authenticate)
-- ## If User activity is within 20m of sessionLast
-- Access is PASSED & update sessionLast, sessionExpires
-- ## If User activity is within sessionExpires
-- Access is PASSED & update sessionLast, sessionExpires

-- #2 FORCE RE-SIGNIN (.authenticate)
-- If User wants to "invalidate all"/"Signout from All devices"
-- sessionForceSignin is set TRUE
-- THEN on next AUTHENTICATE event, User with existing $token is booted out!
-- THEN forced to SIGNIN again (new $token is created & sessionForceSignin is reset to FALSE)

-- DEFINE ACCESS LOGIC ===========================================================
DEFINE ACCESS OVERWRITE user ON DATABASE TYPE RECORD
    SIGNUP (
        CREATE ONLY user SET
            name = $userData.username,
            role = $userData.role,
            email = $userData.email,
            verified = $userData.verified,
            authProvider = $userData.authProvider,
            password = crypto::argon2::generate($userData.password),
            dateCreated = time::now()
            ,
            sessionLast = time::now(),
            sessionExpires = time::now() + 14d, --default time to force re-Signin
            sessionForceSignin = false
            ,
            profile = (CREATE ONLY profile:[$this.id, rand::ulid()] CONTENT $profile).id
    )
 
    SIGNIN ({       
        LET $validUser = (SELECT * FROM user
            WHERE email = $email 
            AND crypto::argon2::compare(password, $password)
        );
        -- RETURN $validUser

        IF (!$validUser) {
            THROW "User invalid - Please Signin again." -- email/password combo incorrect  
        } ELSE {
            -- SIGNOUT ALL DEVICES - RESET
            IF ($validUser.sessionForceSignin) { 
                UPDATE $validUser SET sessionForceSignin = false; -- reset
            };
            
            -- SHORT/LONG EXPIRY - RESET
            UPDATE $validUser.id 
            SET 
                sessionLast = time::now(),
                sessionExpires = time::now() + 14d --extend for 14d
            ;
            RETURN $validUser
        }
    })
 
    AUTHENTICATE ({
        -- SIGNOUT ALL DEVICES - TRIGGER
        IF ($auth.sessionForceSignin) { 
            UPDATE $auth SET sessionForceSignin = false; -- reset
            THROW "User must Signin again." -- force re-Signin
        } ELSE

        -- SHORT EXPIRY (not required)
        -- If current action is within 20m of last action:
        -- PASS & update sessionLast
        IF (time::now() <= $auth.sessionLast + 20m){ -- SHORT not yet expired
            UPDATE $auth.id SET 
                sessionLast = time::now(),
                sessionExpires = time::now() + 14d; --extend for 14d
            RETURN $auth;
        } ELSE
        
        -- LONG EXPIRY
        -- Consider long duration since activity.
        -- If current action is within expiry period:
        -- PASS & update sessionLast & extend sessionExpires
        IF (time::now() <= $auth.sessionExpires){ -- LONG not yet expired
            UPDATE $auth.id SET
                sessionLast = time::now(),
                sessionExpires = time::now() + 14d; --extend for 14d
            RETURN $auth;
        } ELSE {
            THROW "User session expired - Please Signin again." -- session expired
        }
    })
    
    DURATION FOR TOKEN 10y, FOR SESSION 1y;

In hindsight, the setup of SHORT EXPIRY / 20m / using sessionLast is perhaps not necessary... Maybe if I wanted additional controls for a "Shorter Expiry" I'd throw those functions inside there🤔

BTW, to test this in my client, I used these functions to trigger different things and review results in Surrealist:

    sessionStatus: async () => {
        const res = await Sdb.query( /*surql*/ `
            SELECT * FROM $session;
            SELECT * FROM $token;
            SELECT * FROM $auth;
        `)
        console.log('sessionStatus▶', JSON.stringify(res, null, 2));
    },

    authenticateAgain: async (event) => {
        const token = event.cookies.get(COOKIE_NAME_SESSION);

        const res = await Sdb.authenticate(token || "")
        console.log('authenticateAgain▶', JSON.stringify(res, null, 2));
    },

    signOutAllDevices: async () => {
        const res = await Sdb.query( /*surql*/ `
            UPDATE $auth SET sessionForceSignin = true
        ;`)

        console.log('signOutAllDevices▶', JSON.stringify(res, null, 2));
    },

Link to this discussion (if continued) in discord: https://discord.com/channels/902568124350599239/1018618253695795261/1306132221203185705

[adminy]

Even without the refresh mechanism, you could externalise the auth to a third party such as github, which provides accessToken and refreshToken. Then use the short lived github accessToken to get a surrealdb short lived accessToken so that you can have a session for whatever duration you think is appropriate. Then when that expires or you loose it, to re-create a new one, you can use github's refresh mechanism to get an access token, trade that with surreal, to re-instanciate the session. Bonus is that you don't have to store refresh tokens and do the dance twice with surreal, you just do it once with github and once with surreal.