Is it bad practice to put additional claims for authorization-CodePudding

I want to implement authorization layer on my microservices project. I have 3 microservices customer-service, workspace-service and cloud-service. So if a customer want to create a cloud instance he will create on behalf of a workspace which means that the cloud instance will belong to the workspace instead of him and also he may invite other customer to the workspace, and have access to the cloud instance. The data structure may looks like this.

// workspace
{
 "workspaceId": "ws-123",
 "customers": ["customer-123", "customer-456"]
}

// cloud-instance
{
 "cloudId": "cloud-123",
 "workspaceId: "ws-123"
}

I want to implement authorization logic that check if a user has access to a particular cloud instance. In order to do that I need to have workspaceId somewhere else in my authentication object. One thing that I can think of is that to put workspaceId in the jwt claims so my jwt may looks like this.

header.{ ..., workspaceId: ["ws-123"] }.signature

but the drawback of this solution is that the workspaceId claim won't be updated until the token has been refresh.

another solution that is to implement a service that query data from workspace-service and use it to validate.

const hasAccess = (customerId, workspaceId_on_cloud_instance) => {
   let actual_workspaceId_that_he_has = workspace_service_exposed_api.findWorkspaceByCustomerId(customerId)
   return actual_workspaceId_that_he_has == workspaceId_on_cloud_instance
}

but this approach would heavily rely on workspace-service if workspace-service is down then the other service can not handle a request at all since it doesn't have access to workspaceId.

So IMHO I would rather go for the 1st option since I use oauth2.0 and token will be refresh every 30s, but is it bad practice to do that? I wonder if there's better solution.

CodePudding user response：

Having 3 microservices you cannot implement functionality with assumption that one service is down. I have feeling that access token lifespan is also defined based on this restriction - to have up to date data in the token. As I correctly understand, in worst case there is also ~30 sec. delay related to workspaceId update in token payload.

Token claim will change only when you invite or remove person from workspace so this service must work anyway. I would use 2nd solution with longer token lifespan to not generate it so often.

Another solution is to generate new token every time when workspace is changed - you can treat adding/removing to workspace as a business logic that invalidates token, but probably in this case communication to workspace service is also required.

If you are afraid that microservice will be down or you will have problem with communication, maybe you should focus more on app infrastructure or choose a new solution based on monolith application.

And back to question from title - adding any custom claim to token payload is standard approach.