We will be adding features that will allow u to read info of another token called Open ID token

Oh, usually on the front end dont you have access to current user?

Not via the access token

Usually, it’s either an API call to get user’s info

Or via a special token called open id connect

Either is fine really. Doesn’t make much of a difference

Is open ID === user Id in database?

Actually, open ID is a JWT, that contains any info ur frontend might need

It’s like the access token. But it’s only for frontend’s use. It won’t give access to ur APIs

So currently if user needs to join a category for example, the endpoint is users/:userId/categories/:categoryId Typically I would have currentUserId stored on client and then just put that into the request, but instead I need to call an api with access token then receive the ID then make request users/:userId/categories/:categoryId

Yes. U should get the user’s ID in ur app at launch and just store that in memory. So that later u can use it without calling that API again.

But, if this API to add a user can only be called by the current user, then u should not give a userId to the API. The API should get the userId from the session

So most of the time, if ur doing an operation on behalf of the currently logged in user, u should never give the userId in the request. Cause that’s what a session is for.

To ID the currently logged in urser securely

Wait so: User logs in => store ID in memory => user makes a call to /users/:userId(get from memory)/categories/:category Id?

Then you say > But, if this API to add a user can only be called by the current user, then u should not give a userId to the API. The API should get the userId from the session @User What is this situation in comparison?

So ideally, u should never need the currently logged in user’s ID on ur frontend

Oh not in memory?

U can. But ur APIs should not trust the userId in the URL. They should check that that userId is = to the session userId.

In which case, u don’t need to put the userId in the URL

and if u do that, u don’t need to have userId of the currently logged in user on the frontend

That's half what I'm doing

Currently if user makes request users/:userId/categories/:categoryId

My api checks if userId === session.getUserId

If not it throws 401 Unauthorized

If it is, it allows the operation

I see

So in this case, why do u need to put the userId in the URL?

I dont do I really

It could just be /users/categories/:categoryId