Resource server (API) associated user data

[sergio1]

I’ve been going through the documentation to have a SPA+API architecture: https://auth0.com/docs/architecture-scenarios/spa-api/part-3#call-the-api (and also the tutorials to setup an API and a SPA in my languages of choice - https://auth0.com/docs/quickstart/backend/rails/01-authorization and https://auth0.com/docs/quickstart/spa/react/01-login#configure-callback-urls )

One thing I cannot find any clear picture of how it works exactly is, how does the Resource Server (API) associated their data with the user data in the first place. For example, in the SPA-API scenario, to retrieve a list of timesheets for an employee, I’m assuming the employee previously created timesheets in the resource server associated with their’s auth0 user id? What kind of employee/user information is expected to be tracked on the resource server?

Also, at what point is that user information first registered in the resource server? When the first timesheet is created?

One of the gems I’ve found online to integrate Rails API with Auth0, knock https://github.com/nsarno/knock provides a helper that seems to expect the User to exist in the resource server database already.

In my personal case, I’m trying to define an architecture where the user sign ups with Auth0 and that process initiates a registration process where they will need to provide further information. As I understand it, without doing anything else apart from by signing up with Auth0, the user will be tracked in Auth0 but the resource server has no awareness the user exists. Am I supposed to create a user profile in the resource server at this point? And if so who kicks that API request? The SPA?

The expectation is that once the user logs in in the SPA, their profile is checked in the resource server and the user is redirected to the appropriate page depending of what stage of profile filling they’re at.

[nicolas_sabena]

Hi @sergio1. You are on the right track here. WIth a separated API architecture, you can think of the SPA as one possible client, but everything could be done by making direct requests to the API.
The Access Token that Auth0 provides will always contain a sub (subject) claim, a unique identifier for the user, that is guaranteed to be the same on subsequent logins.
If your backend requires registration before it can be used, for example, then when a client application tries to use that Access Token to make requests to the API, the API could reject most requests until the registration phase is completed (returning an error that conveys that “you need to complete the registration first”).
The application needs to be smart enough to understand what can and can’t be done, and present a nice user experience. The application would understand that the error response means that it needs to start asking for the profile information, and do something like a POST to /api/user/register. On the backend API every profile information posted would be associated with the sub contained in the access token.
If it helps building the profile, you can authorize your backend API to access Auth0’s Management API v2 (that’s a separate token obtained by having the API do a client-credentials token exchange). With that token, your backend API can make a request to the /api/v2/users/{user_id} endpoint to get additional information about the user (which might be useful especially if the user logged in with a social identity that provides first name, last name and so on).