I recently came across a project that uses AWS Cognito's ADMIN_USER_PASSWORD_AUTH flow. This method requires users to enter their username and password in a custom UI, which then sends the information to their server. After that, the backend communicates with the Cognito API to retrieve the ID and access tokens. I'm curious about why developers would prefer this approach, which involves their server handling passwords, instead of using OIDC, which allows for a cleaner separation where the app never sees the user's password. Wouldn't it be ideal to avoid handling passwords altogether? Plus, why does AWS even provide this ADMIN_USER_PASSWORD_AUTH flow when OIDC is available?
3 Answers
Haven't you ever used any service with username and password authentication? If the server doesn't get the raw password, how does it know if the password was right? Think about that before dismissing the Cognito method. It's not necessarily bad.
Sometimes, developers stick to what's familiar or easy, especially if they don't fully understand OIDC or how to implement it. If they added Cognito later, it might have just been easier to stick to the existing method instead of overhauling the whole authentication process.
If the team originally built their app around Cognito, they might have just taken the easiest route without realizing OIDC was an option. It's possible they just swapped their local authentication call with a call to Cognito, keeping it simple to avoid introducing errors if OIDC wasn't even on their radar.
To clarify, the app doesn’t need to handle passwords directly. With Cognito, the service manages it and returns authentication results. The app can avoid seeing the password completely, which makes it safer since the IdP is the only entity that gets to see it.