Is there a sample of a login lambda that generates...
# help
f
Is there a sample of a login lambda that generates a JWT based on my cognito user pool? This is given that my frontend is outside of SST
t
you cannot generate a JWT for a user from backend code, one of my biggest reasons for not recommending cognito
or are you talking about triggers?
f
You’re right. I’m using Cognito and want to use JWT
like probably having a
/login
endpoint that returns a JWT
t
you need to have your frontend talk directly to cognito
f
I see. Thank you!
@thdxr btw, if you don’t recommend cognito, what other auth do you recommend?
d
I heavily recommend Cognito, unless you have a very solid reason for not using it. Its about 1/10 the cost of alternatives, besides Firebase.
The command you are looking for is
AdminInitiateAuthCommand
, it takes a variety of possible inputs, but one such variety is username/password and it returns an
AuthenticationResult
, which has a token, refresh token, etc.
As far as I know, there isn’t anything you can do from the frontend that you can’t from the back (and back certainly has significantly more available). At least, we haven’t found anything yet (and we are about 10 cognitos deep at this point).
t
oh if you have the username/pw you can do that, thought you meant through your own mechanism
I don't really have any recommendations over cognito, I've liked Userfront the most. But ultimately I find none of these services really allow you to implement a maximally correct auth flow that is still compatible with things like e2e testing
d
thats actually another one of the possibilities, its called “Custom_Auth”. I havent used it, but it does exist for when you need to work outside of the standard flow.
Heavily recommend might be overselling my feelings as well. Cognito is probably the worst designed AWS service ive come in contact with, but it does one thing mediocrely, for super cheap, which is good enough for us!
Regarding customAuth, @thdxr, its actually pretty cool as far as I remember. You basically just create a trigger lambda that returns true/false based on whatever you want and it either allows/doesnt allow a token based on that. That’s from memory, but its in the ballpark.
i think it may be newer, though, so probably didnt exist when you looked into it, so figured I’d mention.
f
Ohh. This is cool! Was just wondering what other options I have besides Cognito. But this one looks good. I will definitely take a look! Thanks for pointing me in the right direction! I love this community! ❤️
d
Sure thing. One recommendation I learned the hard way: forget custom attributes exist. If you ever want to change them, you have to rebuild cognito from scratch, basically. Just store whatever they are yourself.
t
I actually have used that custom auth setup to do an email link login flow
d
lol, then why the shade? I got no love for Cognito, but in the right light, it looks like a mediocre authN service.
I say this jokingly, but I actually do have a fear that one day Cognito will bite. This exists with all authN, but moreso for this one, so I find horror stories (like custom attributes) important.
t
I have a flow for the perfect b2b auth system that's more or less how slack works. Per workspace logins can be configured independently with SSO or whatever, but also the ability to recover your account with just email if you forgot which workspace you were in
I use this flow to evaluate different auth setups to understand if an auth service is well thought through. Cognito is basically at the bottom here
to do this correctly in cognito, you barely have to use cognito + write all your own custom logic. At which point I question the point of having cognito (esp with its quirks of being impossible to mutate after mistakes) in your stack
a
btw., what is the advantage of slack's system? Is it just so that no user data exists in a central place?
t
IMO it's the most correct for a b2b application. You have seperate user accounts per workspace and each workspace might have its own auth rules. Login with username/pw, login with Google, integrate with Okta SSO, etc. But then there's a bunch of UX questions where if a user only knows about slack.com and doesn't know their workspace, how do they "recover" their account
a
ah, yeah, I guess it makes sense when you consider different auth sources
some day soon, I also will have to rework the whole auth setup of my app...but not today
i'm probably still gonna use cognito, but with a lot of triggers
d
No doubt cognito is at the bottom of any feature list, your opinion makes sense to me, Dax. Let me state more clearly: my opinion is based entirely around using Cognito for the absolute bare minimum in authN functionality, then building everything else around it. In this vein, I think it…works. I base a lot of this opinion on that things around auth tend to be pretty custom anyway, so the custom logic writing scenario fits that for me. If you have an exact requirement that another solution can do out of the box, paying for that can definitely make sense.
g
hey late to the discussion and I also kinda have this long hate/okish relationship with cognito and I think if it wasn't priced cheaply you wouldn't consider it. My personal issues with cognito is that it can be slow to login and then it also has a bunch of hidden options and then some options you can't change after creation - so that is the frustating parts. But as we all love open-source options I think that https://supertokens.com/ is the thing to check out for auth as an alternative. (even though some things are still in development)