V8-archive: Rethink Auth Flow

Created on 6 Sep 2019  路  7Comments  路  Source: directus/v8-archive

This is the API counterpart to this App ticket: https://github.com/directus/app/issues/1342

We'll be discussing how we can improve the entire auth flow for Directus here. @rijkvanzanten will be posting more info shortly...

enhancement optimization

Most helpful comment

@rijkvanzanten - This flow seems achievable at our end.

We can generate cookie based on static token. Below is the basic analysis that how we can generate a cookie.

  • If the logged-in user doesn't have any static token then API will generate it automatically with random string and store it into DB.
  • static token will be encrypted using openssl_encrypt method.
  • If we use only static token for encryption; we don't have multiple version of user token so we must have a unique value as a token.
  • Thus, we should use the combination of static token and Random String which will be differentiated with any special character.

API will send the cookie in response header and APP will consider it instead of JWT auth token.

Any other thoughts on the logic of cookie will be appreciated :)

All 7 comments

NOTE: I use the server API more often than the app, so bear with me.

Is this what you propose: have a login authentication token (JWT) that expires and then a persistent API access token for use with server to server and client to server API access?
That way the authentication from the App is decoupled from the API itself?

Or proposing authentication each time you want to access the API?

I am going to read again to make sure I understand.

@philleepflorence I'm proposing a third way to authenticate with the app: session cookies. This will co-exist with the existing JWT and static token options.

Okay understood, let me read again and comment.

@rijkvanzanten - This flow seems achievable at our end.

We can generate cookie based on static token. Below is the basic analysis that how we can generate a cookie.

  • If the logged-in user doesn't have any static token then API will generate it automatically with random string and store it into DB.
  • static token will be encrypted using openssl_encrypt method.
  • If we use only static token for encryption; we don't have multiple version of user token so we must have a unique value as a token.
  • Thus, we should use the combination of static token and Random String which will be differentiated with any special character.

API will send the cookie in response header and APP will consider it instead of JWT auth token.

Any other thoughts on the logic of cookie will be appreciated :)

Just to be absolutely sure, relying on the single token field for encryption does not mean that the user can only be logged in at 1 place at a time right?

relying on the single token field for encryption does not mean that the user can only be logged in at 1 place at a time right?

Yes. User can login to multiple devices at a same time.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

benhaynes picture benhaynes  路  4Comments

gitlabisbetterthangithub picture gitlabisbetterthangithub  路  3Comments

24js picture 24js  路  3Comments

andgar2010 picture andgar2010  路  3Comments

magikstm picture magikstm  路  3Comments