Alternative token schema

[rhnonose]

Is there a way to declare and use an alternative Token schema?

My usecase requires multiple JWT tokens for a user, which requires some changes in the schema (mainly the primary keys).

A suggestion would be for it to be configurable, example:

config :guardian_db, GuardianDb,
  repo: MyApp.Repo,
  token: MyApp.Token

[doomspork]

@rhnonose this isn't something that currently exists but I would be open to exploring this set of functionality. @ueberauth/core what to do you think about the proposed change?

[doomspork]

@ueberauth/developers any thoughts on this proposal?

[yordis]

@doomspork it shouldn't be that complicate as long as there is a defined protocol but why would the primary keys change? I am guessing you want to add user_id to the table?

One solution is add an extra layer on the database relationship instead of touching this table direction, no?

Users [1 ----- ] Tokens [1 ----- ] Guardian Tokens

Anyway the foreign key will pass to Tokens table. So you could have many tokens per user.

[rhnonose]

@yordis that's similar to my workaround, but looks clumsy to me. Not sure if other people have similar problems, that's why I opened here.

[yordis]

@rhnonose well normalization of database could be a debate here. That wouldn't be a workaround for me at all because you are normalizing your table schemas.

In my opinion (because normalization is an art) Guardian Tokens should be agnostic or your environment and right now it is holding a really normalized data.

Adding configuration is fine but for this situation is just complicating the package for small gains overall. Definitely I wouldn't do it for this situation. You didn't do any workaround, you did what is right to do 😄

[yordis]

Unless you want to talk about doing join tables and performance at that level, which I don't see the point either. At that moment your whole architecture will change and you shouldn't be using guardian db 😄

[hassox]

Not sure I understand the problem. The primary key of the tokens table is jti + aud . Both standard fields from jet and nothing to do with the user. The jti should be globally unique so I'm not sure I understand the reason to require different primary keys here

[yordis]

@hassox probably because he has more than one token per user he wants to save the user_id or some soft of key that identify the owner of the token, which in that case he will need to add some column.

[hassox]

Perhaps we should update it to also save the token module that looks after it?

[yordis]

@hassox what do you mean by that?

[hassox]

When we save the data, we could also save the token module name that generated it so we can see what's going on. You can use the token to get the resource from the token. Tbh I don't have too much of a preference. We can work to be able to swap out the token as part of the work that is going on to make adapater based handlers perhaps

[yordis]

As I explained in https://github.com/ueberauth/guardian_db/issues/71#issuecomment-350494393

Just do the following database design Users [1 ----- *] Tokens [1 ----- *] Guardian Tokens.

Allowing this to be swappable is a rabbit hole for us as maintainers and in terms of the database, this is normalized enough.