We have a product which ties a set of resources to a concrete user. Now we would like to provide the customers with an API so that an automated client application can have access to a subset of a concrete user's resources. A single user's resources can be accessed by multiple client applications (potentially with different scopes)
Implementation and architecture details:
We have a server which acts as a resource server and as a web application server at the same time. The Amazon Cognito service is being used as an identity provider and an authorization server.
What is a viable and secure approach to: - Associate a user with multiple clients. - Handle authorization logic.
What we are currently considering:
We are thinking of mapping a registered (in Cognito) client application to a user in our database (the users are one to one mapped to users in a Cognito user pool). From then on we have to put authorization logic somewhere and we think that there are two possible locations:
- Option 1: Use the "Pre Token Generation" lambda trigger (provided by Cognito) to request from our application server the user which is mapped to the client application that is to be authorized then attach claims to the token which the resource server will use to identify which user's resources to serve to the client application - hence the client application will have successfully accessed it's mapped user's resources.
- Option 2: Move the lambda logic to the resource server, a.k.a. extract the registered client application from the database via the token claims and then find out which is the corresponding user and do some authorization logic there.
The difference between the two is that "Option 1" sends the mapping to a Cognito lambda and the token already contains the authorization while "Option 2" does the authorization on the resource server.
What is a secure and scalable way to tie a client application to a user and where (and how) is the client to be authorized?