nhost / hasura-auth

Authentication for Hasura.
https://nhost.io
MIT License
386 stars 114 forks source link

support for PAT in hasura-auth #364

Closed dbarrosop closed 1 year ago

dbarrosop commented 1 year ago

Motivation

Today when a user needs to interact with a hasura-auth/hasura backed service outside of a frontend application they have two options:

  1. Share the admin secret
  2. Implement something customized (like we did ourselves for the cli)

Goal

The goal is to be able to generate tokens to authenticate a backend service or tool as a user. For instance, a cli tool, or some backend service that needs access to hasura.

Potential implementation

A potential implementation could to simply rely on the existing refresh-tokens functionality. In this scenario, a tool like the cli could:

  1. Authenticate the user as normally done
  2. Have the user request a PAT
  3. Store it

At this point the CLI could just reuse that refresh token and act on behalf of the user.

A similar workflow could be used to authenticate backend services:

  1. An admin could create a "service account"
  2. Give it a role that has permissions to do what the backend service needs to do
  3. Create a PAT/refresh_token
  4. Configure it in the backend service

Requirements

For this to work I guess we need:

  1. A mechanism to generate refresh tokens with a longer timespan, i.e., 1 year, 2 years, 99 years....
  2. A mechanism to list them and invalidate them

Security implications

The benefit of this mechanism is that the PAT needs to be authenticated every time to generate an access token so it can be revoked anytime.

compiaffe commented 7 months ago

@szilarddoro Is it possible to list and invalidate the tokens as well? I can't find any documentation about that.

dbarrosop commented 7 months ago

You have them all in the auth.refresh_tokens table which means you can query them and delete them as needed. Just avoid inserting them yourself.