Automatically add claims (e.g. sub) to remote api address?

[ADringer]

Hi,

I'm trying to use remote apis and just wondering if it's possible to do something like this:

app.MapRemoteBffApiEndpoint("/api/books", $"https://remoteHost/users/{userId}/books")

Where userId is retrieved from the sub claim of the current access token.

I know I can use embedded apis for this, but seeing if there is a shortcut for this as I don't currently need to do any logic or transformation, just use the user id from the token.

[wcabus]

The easiest method to go about this, would be to move the responsibility for generating the user-specific route on the frontend:

• The frontend has access to the user claims by querying the /bff/user endpoint. This gives you the sub claim to use as userId in the API route.
• In the BFF, add another remote API endpoint:

  app.MapRemoteBffApiEndpoint("/api/users", "https://remoteHost/users")

• In the frontend again, rewrite the API call to go to https://bffHost/api/users/{sub-claim-value}/books

Another way to solve this on the BFF side, is to add a local API endpoint. In that endpoint's handler code, you can then also extract the sub claim for the current user and call the remote API.

There may be another way to solve this that more aligns with your suggestion, but that will rather require custom Yarp configuration and extensions, which is out of scope for our BFF library.

[ADringer]

Thanks for the reply.

I'm not sure about doing it on the frontend, doesn't feel as secure allowing the frontend to decide which user to retrieve.

Yes I did think it would have to be done using local APIs, but wanted to check that there wasn't any easier way round it.

Thanks!

[wcabus]

Regardless of where you add the userId to the remote API's route, you would still (have to) have additional authorization checks on the API side, to verify that the user who's requesting the URI actually has access to that resource.

[ADringer]

My API is private and agnostic to who is requesting it, it can be given any user id and would return the details. But the BFF (the only route to the API) would be doing the authorization as it would only supply the id of the user in the token, nothing else could be supplied. But yeah, looks like local API is required to pull out the user id claim and build up the url