How to display user activities/actions within application (Best Practices)

Summary:
As users take actions within our application (update forms, post new creations, download artifacts, etc) our application needs to save who did what for auditing and logging. Finally, we need to be able to display that information back to our end users. What information from an Auth0 user ID token is best to save and how to display it back in a human consumable way? What is the fastest way to get this information back to an end-user?

Sample Use Case Story:

Jack, auth0 user ID: “auth0|5b5ehashhashhash”, authenticates with Auth0 and has his user roles checked within our system. Jack edits a form and submits and update to it. The system authorizes him against his roles and allows the action. Along with the new form edits we log whom last edited it (Jack) and the time it was edited. Jack can now see the updated form and that he is the last editor of it. Specifically, Jack see’s his user-chosen nickname “Jack” as the last editor and the system has securely saved a value representing “Jack” that may or may not be his user ID, his nick name or some combination thereof.

Jim now logs in and wants to see who all has been editing documents. Jim queries the system and receives back a list of User Information Values that allow him to see various user-chosen nicknames representing themselves. This way Jim knows that Jack modified a document that he wasn’t supposed.

Assumed Implementation:
Our system should store the Auth0 customer ID for every action a user takes and should pluck that customer ID out of the auth Token that is passed in on every request. Then, upon retrieval, the system should query Auth0 for each of the unique customer IDs and return back to the UI/end-user a fully populated object of the customer ID and that user’s chosen nick-name for display purposes (along with any other system proprietary data that was requested). This implementation makes data retrieval take slightly longer as a second lookup call to Auth0 must be made before returning data to the UI.

Alternative Implementation:
Our system should store the Auth0 customer ID for every action a user takes and should pluck that customer ID out of the auth Token that is passed in on every request. Then, upon retrieval, the server sends to the UI the customer ID. If the UI wants to display more information about that ID (like the nick-name) an additional query will be made that fetches that user’s information. Thus a total of two calls will be made: 1) server stored data 2) any user nick-names we wish to display. That way the penalty for user lookup could be separated if there is value in the data before knowing the usernames.

Ideal Implementation:
User nickname and User Id is returned from the server and the nickname doesn’t get out of sync with updates made to Auth0 without having to pay expensive time looking up values.

Hey there!

Sorry for such delay in response! We’re doing our best in providing the best developer support experience out there, but sometimes the number of incoming questions is just too big for our bandwidth. Sorry for such inconvenience!

Do you still require further assistance from us?