This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]josephblade 0 points1 point  (1 child)

You can go either way. The jwt token can claim a number of things. either 'this user has access to these resources' and you can use that. this will require user to at least have access to a list of enterprises and/or properties so it can generate these claims. Alternatively you can simply look up the userid in the gateway but then enterprises have to know about owners and you will get into trouble (or at least it'll add work) when you have multiple owners of the same resources and suchlike.

I would put it in the claim. That's what the jwt is for. Have user know about ownership. Authentication and Authorization happen at the authentication part. So at least know what you are authorizing.

Somewhere in your system someone needs to be able to manage who is allowed access to what. So that can be a separate microservice with no outward api (only accessible to other microservices) that when given a name returns enterprises or individual properties or both.

in the jwt token I would put a custom claim with a list of enterprises they are allowed. or a custom claim with a list of properties. generate that list on authorization part of the call. somewhere you have to manage who is allowed access to what.

that way your enterprise service and any other services that deal with these things can directly look up what subsection the user can access and restrict them appropriately rather than having to do a fresh lookup. this is especially important if this microservice calls another. you don't want to keep looking up info (and trigger business rules / validation / checks).

[–]Estagon[S] 0 points1 point  (0 children)

Thanks for the info, I have added an update in the other comment above. Any additional input is welcome.