1

I have a question about what's the best approach to handle persistent data for web apps.

I have a web app that is authenticating through an auth service. once authenticated it makes requests to the resource server.

However, when a user logs in, they want the display settings of the web app to be consistent regardless of the session or what browser they use.

There will be a lot of user settings but for the sequence diagram let's just say there is one, Dark mode.

Would it be better to keep user settings as claims in the ID token or would it be better to keep user settings inside a database in the backend?

For both cases the initial returned settings would be

{
    darkMode: true
}

And the updated setting would look like

{
    darkMode: false
}

The only difference is for case number 1 the settings would be inside the ID token JWT payload and for case 2 it would simply be a JSON response.

Important Considerations

  • We don't use the same auth service for all of our environments. we use keycloak in some cases and auth0 in others.
  • there will be lots of settings not just dark mode.

Case1: User Settings in Auth Service User Settings in Auth Service Case2: User Settings in Backend DB User Settings in Backend DB

2
  • The JWT token is not the place for settings; normally they're in the database?
    – pjc50
    Commented Sep 22, 2023 at 12:45
  • if i remove a user from the the auth service i don't want it to still be in the backend db
    – BigL
    Commented Sep 22, 2023 at 12:54

1 Answer 1

0

better to keep user settings inside a database in the backend?

Yes, definitely.

You have multiple authentication services. So that already suggests you'd want to store settings in a single, separate datastore.

Additionally it makes sense for settings to come back as a simple JSON response; they don't belong inside the ID token JWT payload.


If i remove a user from the the auth service i don't want it to still be in the backend db.

That is a perfectly good invariant for your system to preserve. It's just another requirement. But eventual consistency suffices. It's not like we need an immediate update across services.

Clearly you can define convenience methods / endpoints / CLI tools which make it easy to issue a multi-service update. But you should probably also run a midnight report that examines diffs between usernames in one service against another service. That will let you clean things up, and assess how smoothly your (bug free?) tools are working in practice. Over time, often the documentation or the human element will turn out to be the weakest link in coordinating such a system-of-systems.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.