Question on security with Cognito UserPools: If we're doing a monorepo, and we anticipate sharing said UserPool across multiple microservices, then it's likely a common pattern to use cross-stack references?

Hey @Luke Wyman, r u asking if you export the cognito user pool values in 1 stack and importing it into another stack introduces security issues?

Hi @Frank - no, not the security issues. The shared resource I'm working on is coincidentally about security. I'm asking about cross-stack references in general. Looking at the sst constructs, what is the approach/syntax for my microservice stacks, say

SingersStack.ts

,

PerformanceHistoryStack.ts

, etc, to reference

CognitoStack.ts

and apply the Cognito Pool to the APIs in those microservices.

Ah I see. Just to clarify, are you just using the Cognito User Pool as a JWT authorizer? Or are you using the

sst.Auth

construct?

That's something I haven't decided yet. I'm currently doing all the Cognito/JWT/Auth0 examples in the documentation and researching all this in general before I pick a strategy for my app. What I know in advance, is that I'll have a Cognito stack of some sort or other, and that I'll want to share it with my microservices. I can repost here when I have a crisper picture of what I want to do.

Yeah, there are two common ways to implement API auth: using the

Auth

construct or using the JWT token issued by Auth0,

Cognito User Pool

or any third party auth provider.

Okay. So, say that the following are a couple lines from my example code:

const auth = new sst.Auth(this, 'Auth', {
      facebook: { appId: 'xxxxxxxxxxx'},
    });

    auth.attachPermissionsForAuthUsers([api]);

but that

auth

and

api

live in different

____Stack.ts

files. What is the syntax/technique for of connecting the two in the

auth.attachPermissions...

line? Can I just export the

auth

in it's

.ts

file and import it in my

MicroserviceStack.ts

file?

ie. in

lib/AuthStack.ts

const auth = new sst.Auth(...);
this.auth = auth;

in

lib/index.ts

const authStack = new AuthStack(app, "auth");
new ApiStack(app, "api", { auth: apiStack.auth });

in

lib/ApiStack.ts

const api = new sst.Api(...);
props.auth.attachPermissionsForAuthUsers([api]);

Awesome! Thanks, Frank 🙂

Yup!

So this seems to work, but doesn’t it then require that AuthStack must be deployed at the same time as ApiStack? Would it make more sense to share the values as SSM parameters and use fromXXX to get the resource?

Hey @Erik Mikkelson, yeah you could store the Api id as an SSM parameters, and then reference the SSM value when creating the Identity Pool’s authenticated IAM role.

@Frank Even though I’ve used the CDK for a bit there are a few places I am missing some understandings so forgive crazy ideas. I am trying to think a bit about an individual and shared developer experience. An individual developer is going to want some local development with services under tight control (I think most easily accomplished for initial lambda development by unit tests with mocks for aws services and generated test data. We’re using rushjs and pnpm so that made VSCode debugging interesting until I created a helper script to launch tests under the context of the target package). Once they have that working, it makes sense for them to deploy developer environments if they need it. We’re already planning on separating out the stacks into layers based on the amount of change (the three layers) Not all developers are going to deploy their own user pools and aurora DBs (which are more expensive in terms of deployment time and general cost), so in cases where they could reuse a shared user pool, database, and perhaps even some of the s3 buckets for assets I’d like to at least investigate that. In order to do that, you can’t have such a hard link between the stacks. Storing the resource arns as outputs for a stage in the parameter store where they can be looked up on deploy makes more sense.

Gotcha. As for $ cost, if each developer has their own AWS account, hence free tier, then you can have ie. an Aurora DB cluster of size 1 running a small instance for free.

@Frank You mean their own AWS account as in actually different accounts (different credit cards, etc) or AWS Organizations?

Sub accounts within the same AWS Organization. Each has their own free tier.

I did not know that, thank you for the information!