How can I generate a compatible refresh token for jwt-refresh

[joseargao]

I am hoping to add an additional way to log in to a rodauth app, using just an access code. To that end, I thought I might be able to make this happen in before_login_route. The access token I encoded seems to work for accessing my endpoints, but when I try to use my refresh_token I get an "invalid JWT refresh token" error.

Is there something missing or wrong with the way I generated the refresh token? Is there perhaps a better way of accomplishing what I am trying to do? Any advice would be appreciated.

    before_login_route do
      access_code_param = request.params['access_code']
      if access_code_param
        access_code = AccessCode.find_by(code: access_code_param)

        if access_code&.account && !access_code.expired?
          access_code.use!

          jwt_session_hash["account_id"] = access_code&.account_id
          access_token = JWT.encode(jwt_session_hash, jwt_secret, jwt_algorithm)

          refresh_key = SecureRandom.urlsafe_base64(32)
          refresh_token_record = AccountJwtRefreshKey.create!(
            account_id: access_code&.account_id,
            key: refresh_key,
            created_at: Time.now,
            deadline: Time.now + jwt_refresh_token_deadline_interval
          )
          refresh_token = "#{access_code&.account_id}_#{refresh_token_record.id}_#{convert_token_key(refresh_key)}"
          set_jwt_refresh_token_hmac_session_key(refresh_token)

          response.status = 200
          response.write JSON.generate({
                                         success: "You have been logged in",
                                         access_token:,
                                         refresh_token:
                                       })
        else
          response.status = 401
          response.write JSON.generate({ error: "Invalid or expired access code" })
        end
        request.halt
      end
    end

[joseargao]

Upon further investigation, the problem seems to be in the way I am creating the access token. When I checked the authorization section of the response header, the encoded data included:

{"exp"=>"1719522313",
 "iat"=>1719479113,
 "nbf"=>1719479108,
 "account_id"=>856,
 "jwt_refresh_token_data"=>"q7LXOWeggwv3IaQOqC9k9LHo2I295g7_cbUBx4PUHhs",
 "jwt_refresh_token_hash"=>"7qzL3GRPQySUI-sw-ogR1cI2Ypw8mkBh0A1aL8Gw9k4",
 "authenticated_by"=>["password"]}

However, the one I am generating has less data:

{"exp"=>"1719522313",
  "iat"=>1719479113,
  "nbf"=>1719479108,
  "account_id"=>856}

I will see if I can generate a token that matches exactly. But I am still open to advice in case there is a better way to do this.

[joseargao]

I was able to match the token in the header by simply referencing session_jwt, but for that to work I needed to execute set_jwt_refresh_token_hmac_session_key on my refresh key. The updated code looks like this:

    before_login_route do
      access_code_param = request.params['access_code']
      if access_code_param
        access_code = AccessCode.find_by(code: access_code_param)

        if access_code&.account && !access_code.expired?
          access_code.use!

          jwt_session_hash["account_id"] = access_code&.account_id

          refresh_token_deadline_interval = jwt_refresh_token_deadline_interval || 14.days
          refresh_key = SecureRandom.urlsafe_base64(32)
          refresh_token_record = AccountJwtRefreshKey.create!(
            account_id: access_code&.account_id,
            key: refresh_key,
            created_at: Time.now,
            deadline: refresh_token_deadline_interval
          )
          refresh_token = "#{access_code&.account_id}_#{refresh_token_record.id}_#{convert_token_key(refresh_key)}"
          set_jwt_refresh_token_hmac_session_key(refresh_token)

          response.status = 200
          response.write JSON.generate({
                                         success: "You have been logged in",
                                         access_token: session_jwt,
                                         refresh_token:
                                       })
        else
          response.status = 401
          response.write JSON.generate({ error: "Invalid or expired access code" })
        end
        request.halt
      end
    end

This looks like it works based on my initial testing. I am still open to advice in case there is a better way to do this.

[jeremyevans]

If you are trying to add an alternative login method, you should probably see how the login feature works. Assuming the access code is valid:

  if account = access_code&.account
    @account = account
    login('access_code')
  end

FWIW, non-account-specific access codes are a bad security idea, and Rodauth avoids them. You also do not appear to be using a timing-safe approach for access code matching. See https://rodauth.jeremyevans.net/rdoc/files/README_rdoc.html#label-Tokens . I recommend reconsidering your approach.

[joseargao]

Thank you for the response @jeremyevans it was quite helpful. I have incorporated the login feature and I will read through the document you linked.

Just to clarify, the access codes will still be tied to accounts. Our use case involves multiple interdependent devices needing to log in to the same account, and the first log in will always use the standard username/password method. This account can then generate an access code that will allow the rest of the devices to log in without having to enter the same credentials repeatedly.

[jeremyevans]

Access codes are tied to accounts in your example code, but you are not looking up the account, and then comparing the access code for the account to the given access code in a timing safe manner. You appear to be looking up an access code using a database query, and then finding the account related to it. That's not as secure an approach as what Rodauth uses for the tokens it uses in other features. It isn't timing-safe, and it allows for brute forcing against all available access tokens instead of only for a single account's access token. It's at least a theoretical vulnerability in your implementation, even if exploiting such an attack may not be feasible. This may not be an issue if security is not that important in your application.

[joseargao]

@jeremyevans I see what you mean now. Thank you for pointing out the vulnerability.