import { type ProviderIdentity } from "./provider.js"; /** * Become two real signed-in Amazon Cognito users. * * Cognito's user pool API is JSON over HTTPS with the operation in an * `X-Amz-Target` header. The admin operations are authorized with IAM * credentials and therefore need SigV4 signing, which is why this file carries * a signer; the one operation that proves the identity does not, which is what * makes the proof provider-mediated rather than inferred. * * 1. `AdminCreateUser` with `MessageAction: "SUPPRESS"` creates the user * without sending them an invitation email. The reply's `User.Attributes` * carries `sub` — the immutable id that appears in every token and in an * application's owner column. `Username` is what the pool knows them by * and is *not* the same thing. * 2. `AdminSetUserPassword` with `Permanent: true` clears the * `FORCE_CHANGE_PASSWORD` state a created user starts in. Without it every * sign-in comes back as a `NEW_PASSWORD_REQUIRED` challenge rather than as * tokens. * 3. `AdminInitiateAuth` with `AuthFlow: "ADMIN_USER_PASSWORD_AUTH"` and * `AuthParameters: { USERNAME, PASSWORD }` returns * `AuthenticationResult` with `IdToken` and `AccessToken`. The app client * must have `ALLOW_ADMIN_USER_PASSWORD_AUTH` enabled; a pool that does not * is a refusal rather than a fallback. A response carrying a * `ChallengeName` instead is not a session and is not treated as one. * 4. `GetUser` with `{ AccessToken }` names the account. Cognito documents * that it "doesn't evaluate AWS Identity and Access Management (IAM) * policies in requests for this API operation" — it is authorized by the * user's own token — so this is the provider answering as the user, not as * the administrator. Its `sub` attribute has to be the one step 1 * returned. * * Built from the Amazon Cognito user pools API reference: * https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUser.html, * .../API_AdminSetUserPassword.html, .../API_AdminInitiateAuth.html and * .../API_GetUser.html, and the SigV4 process at * https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html. * * ## Which token is sent * * The **ID token**. It is what a Cognito authorizer validates by default and * what a Next.js or Express application verifying `aud` against its app client * id expects; its `sub` is the same immutable id the rows were planted under. * An application that validates the access token instead will refuse it, and * that refusal shows up as the owner check failing rather than as a finding — * `api.auth.token: "access"` switches it. */ export interface CognitoAdminAuth { kind: "cognito_admin"; /** e.g. `eu-west-1_AbCdEf123`. The region is read from it when not given. */ userPoolId: string; /** The app client with `ALLOW_ADMIN_USER_PASSWORD_AUTH` enabled. */ clientId: string; region?: string; accessKeyId: string; secretAccessKey: string; sessionToken?: string; /** Which token the application validates. Defaults to the ID token. */ token?: "id" | "access"; /** Override for the API root, for a test double. */ apiUrl?: string; } export declare function becomeCognitoUsers(auth: CognitoAdminAuth): Promise; /** `eu-west-1_AbCdEf123` → `eu-west-1`. */ export declare function regionOf(userPoolId: string): string; interface SigningInput { method: string; path: string; headers: Record; payload: string; region: string; amzDate: string; accessKeyId: string; secretAccessKey: string; } /** * AWS Signature Version 4, as an `Authorization` header value. * * Written out rather than pulled in with the AWS SDK, which would be a * multi-megabyte dependency in a tool whose whole pitch is `npx crossline` with * nothing to install. It is exercised end to end against a stub that recomputes * the signature and rejects a wrong one, so a mistake here fails the suite * rather than showing up as a provider refusal a developer has to decode. */ export declare function sign(input: SigningInput): string; export {};