Brugeradministration med AWS Cognito - (1/3) Første opsætning

Den komplette AWS Web Boilerplate - Tutorial 1A

Main Indholdsfortegnelse Klik her Del A: Indledende opsætning Del B: kernefunktionaliteten Del C: Sidste trin til fuldt udbygget

Download Github her.

Introduktion

Opsætning af brugergodkendelse kan tage aldre, men det er en vigtig hjørnesten i enhver produktionsapp. Der er muligheder derude som AuthO og PassportJS, men de har enten hårde læringskurver, kræver løbende vedligeholdelse eller er sårbare over for programmeringsfejl, da de kræver selvkonfiguration. Hvis der kun var en hands-off, tilpasselig, sikker og meget skalerbar brugeradministrationstjeneste i skyen.

Introduktion til Amazon Cognito og Federated Identities. Cognito er AWS-løsningen til styring af brugerprofiler, og Federated Identities hjælper med at holde styr på dine brugere på tværs af flere login. Integreret i AWS-økosystemet åbner AWS Cognito en verden af ​​muligheder for avanceret frontend-udvikling, da Cognito + IAM-roller giver dig selektiv sikker adgang til andre AWS-tjenester. Vil du kun tillade S3 Bucket-adgang til specifikke brugere, der er logget på? Forbind blot et Cognito-login med en IAM-rolle, der har adgang til skovlen, og nu er din skovl sikker! Bedst af alt, det gratis niveau giver dig 50.000 aktive brugere hver måned, så du behøver ikke bekymre dig om at betale mere, før du er klar til at springe op.

Denne kedelplade er en React-Redux webapp, der har alle funktioner i AWS Cognito og Federated Identities præintegreret. Brug denne kedelplade, hvis du har en app, som du vil have udviklet med en produktionsklar godkendelsestjeneste lige fra starten. Faktisk er dette en kraftfuld startplade til din næste gode idé.

Gå til AWS Cognito på AWS-konsollen for at komme i gang!

Første opsætning - Cognito

Vi opretter AWS Cognito, som er en brugerdefineret loginpulje (såsom login med e-mail). Cognito ER IKKE en loginmanager til nogen form for login (såsom Facebook og Gmail), kun til brugerdefinerede logins.

Lad os først oprette en brugerpulje ved at klikke på "Administrer dine brugerpuljer". En brugerpulje er en gruppe brugere, der opfylder den samme betegnelse. Hvis du lavede en Uber-klon, ville du oprette 2 brugerpools - en til chauffører og en til ryttere. Lad os lige nu oprette 1 ny brugerpulje kaldet "App_Users". Opsætningsskærmen skal se sådan ud:

Vi går igennem denne proces trin for trin, så indtast poolnavnet "App_Users" og klik på "Step through settings". Det næste trin er "Attributter", hvor vi definerer de attributter, som vores "App_Users" vil have.

Vi ønsker nu kun at have en e-mail, adgangskode og "agentnavn". E-mailen er vores unikke id for en bruger, og adgangskoden er et obligatorisk felt (det er derfor, du ikke kan se det på listen over standardattributter). Vi ønsker, at brugerne skal have et kodenavn at gå efter, så lad os oprette "agentName" er en brugerdefineret attribut. Vi bruger kun “agentnavn” til at vise, hvordan vi tilføjer tilpassede attributter. Rul ned, og du vil se muligheden for at tilføje tilpassede attributter.

Fra den dato, hvor denne tutorial blev skrevet, kan du ikke gå tilbage og ændre de brugerdefinerede attributter (selvom AWS ser ud til at være i stand til det), så sørg for at få det rigtigt første gang! Hvis du har brug for at ændre attributter, skal du oprette en ny brugerpulje. Forhåbentlig løser AWS dette problem snart. Under alle omstændigheder går vi videre til kontopolitikker!

Så vi kan her se, at vores adgangskoder kan håndhæves for at kræve bestemte tegn. Det er klart, at det er mere sikkert at kræve en blanding af forskellige karaktertyper, men det kan brugerne ofte ikke lide. For en mellemvej, lad os bare kræve, at adgangskoden skal være mere end 8 tegn og inkludere mindst 1 nummer. Vi ønsker også, at brugerne skal kunne tilmelde sig. De andre dele er ikke så vigtige, så lad os gå videre til næste trin: verifikationer.

Denne del er sej, vi kan nemt integrere multifaktorautentificering (MFA). Dette betyder, at brugerne skal tilmelde sig en e-mail samt en anden form for godkendelse, såsom et telefonnummer. En PIN-kode sendes til dette telefonnummer, og brugeren bruger den til at bekræfte deres konto. Vi bruger ikke MFA i denne vejledning, kun e-mail-verifikation. Sæt MFA til "fra" og markér kun "E-mail" som en verifikationsmetode. Vi kan forlade den "AppUsers-SMS-rolle" (IAM-rolle), der er udfyldt, da vi ikke bruger den, men muligvis bruger den i fremtiden. Cognito bruger denne IAM-rolle for at være autoriseret til at sende SMS-beskeder, der bruges i MFA. Da vi ikke bruger MFA, kan vi gå videre til: Beskedtilpasninger.

Når brugere modtager deres e-mail-kontobekræftelse, kan vi specificere, hvad der indgår i den e-mail. Her har vi lavet en brugerdefineret e-mail og programmeret placeret i bekræftelses-PIN-koden repræsenteret som {####}. Desværre kan vi ikke videregive andre variabler såsom et verifikationslink. For at opnå dette er vi nødt til at bruge en kombination af AWS Lambda og AWS SES.

Rul ned på siden i trinnet Beskedtilpasning, og vi kan tilføje vores egne standard FROM- og SVAR-TIL-adresser. For at gøre dette skal vi verificere en e-mail i AWS SES, som er let og super hurtig at konfigurere. Gå til AWS-konsolens startside på en ny fane ved at klikke på den orange terning øverst til venstre. På konsolens startside skal du søge efter SES (Simple Email Service). Klik for at gå til SES-siden, og klik derefter på linket E-mail-adresser i menuen til venstre.

Klik derefter på "Bekræft en ny adresse", og indtast den e-mail, du vil bekræfte.

Log nu ind på din e-mail og åbn e-mailen fra AWS. Klik på linket inde i e-mailen for at bekræfte, og du vil blive omdirigeret til AWS SES-siden igen. Du har bekræftet en e-mail! Det var let.

Nu er det gjort, lad os vende tilbage til AWS Cognito og gå videre til: Tags.

Det er ikke obligatorisk at tilføje tags til en brugerpulje, men det er bestemt nyttigt til styring af mange AWS-tjenester. Lad os bare tilføje et tag til 'AppName' og indstille det til værdien 'MyApp'. Vi kan nu gå videre til: Enheder.

Vi kan vælge at huske vores brugers enheder. Jeg vælger normalt "Altid", fordi det at huske brugerenheder både er gratis og ikke kræver nogen kodning fra vores side. Oplysningerne er også nyttige, så hvorfor ikke? Næste trin: Apps.

Vi ønsker, at visse apps skal have adgang til vores brugerpulje. Disse apps er ikke til stede andre steder på AWS-økosystemet, hvilket betyder, at når vi opretter en "app", er det en kun-kognito-identifikator. Apps er nyttige, fordi vi kan have flere apps, der får adgang til den samme brugerpulje (forestil dig en Uber-klonapp og en gratis Driving Test Practice-app). Vi sætter opdateringstokenet til 30 dage, hvilket betyder, at hvert loginforsøg returnerer et opdateringstoken, som vi kan bruge til godkendelse i stedet for at logge ind hver gang. Vi afklikker på "Generer klienthemmelighed", fordi vi har til hensigt at logge ind på vores brugerpulje fra frontenden i stedet for bagenden (ergo, vi kan ikke gemme hemmeligheder i frontenden, fordi det er usikkert). Klik på "Opret app" og derefter "Næste trin" for at gå videre til: Udløsere.

Vi kan udløse forskellige handlinger i brugergodkendelse og opsætningsflow. Kan du huske, hvordan vi sagde, at vi kan oprette mere komplekse e-mail-kontoverifikationer ved hjælp af AWS Lambda og AWS SES? Det er her, vi ville sætte det op. For omfanget af denne vejledning bruger vi ikke AWS Lambda-udløsere. Lad os gå videre til det sidste trin: Gennemgang.

Her gennemgår vi alle de konfigurationskonfigurationer, vi har lavet. Hvis du er sikker på disse oplysninger, skal du klikke på "Opret pool", så bliver vores Cognito User Pool genereret!

Vær opmærksom på pool-id'en us-east-1_6i5p2Fwaoi fanen Pooloplysninger.

Og app-klient-id'et 5jr0qvudipsikhk2n1ltcq684bi fanen Apps. Vi har brug for begge disse i vores klientside-app.

Nu hvor Cognito er oprettet, kan vi oprette Federated Identities til flere login-udbydere. I denne vejledning dækker vi ikke detaljerne ved FB Login, da det ikke er inden for rammerne af denne tutorial-serie. Imidlertid er det super nemt at integrere FB Login, og vi viser, hvordan det gøres i nedenstående afsnit.

Første opsætning - Forenede identiteter

Dernæst vil vi opsætte "Federated Identities". Hvis vi har en app, der tillader flere loginudbydere (Amazon Cognito, Facebook, Gmail..etc) til den samme bruger, ville vi bruge Federated Identities til at centralisere alle disse login. I denne vejledning bruger vi både vores Amazon Cognito-login såvel som et potentielt Facebook-login. Gå til Federated Identities, og start processen med at oprette en ny identitetspulje. Giv det et passende navn.

Udvid nu afsnittet "Udbydere af godkendelse", og du vil se nedenstående skærmbillede. Under Cognito skal vi tilføje den Cognito User Pool, som vi lige har oprettet. Kopier og indsæt det brugerpool-id og den app-klient-id, som vi tidligere har noteret os.

Og hvis vi ønskede Facebook-login til den samme brugeridentitetspulje, kan vi gå til fanen Facebook og blot indtaste vores Facebook-app-id. Det er alt der er til det på AWS-konsollen!

Gem identitetspuljen, og du vil blive omdirigeret til nedenstående skærmbillede, hvor IAM-roller oprettes for at repræsentere den Federated Identity Pool. Den ikke-godkendte IAM-rolle er for ikke-loggede brugere, og den godkendte version er for loggede brugere. Vi kan give disse IAM-roller tilladelse til at få adgang til andre AWS-ressourcer som S3-skovle og lignende. Sådan opnår vi større sikkerhed ved at integrere vores app i hele AWS-økosystemet. Fortsæt med at oprette denne identitetspulje.

Du skal nu se nedenstående skærm efter succesfuld oprettelse af identitetspuljen. Du behøver nu kun at notere en ting, der er Identity Pool ID (dvs. us-east-1:65bd1e7d-546c-4f8c-b1bc-9e3e571cfaa7), som vi vil bruge senere i vores kode. Store!

Afslut alt og gå tilbage til AWS Cognito hovedskærm. Hvis vi går ind i sektionen Cognito eller sektionen Federated Identities, ser vi, at vi har de 2 nødvendige puljer oprettet. AWS Cognito og AWS Federated Identities er klar til at gå!

Det er alt til opsætning! Med disse 2 puljer kan vi integrere resten af ​​vores kode i Amazons komplette godkendelsestjeneste og opnå højeste brugerstyring. Det var langt nemmere end brugerdefineret OAuth + Passport.js! Hvis du kan lide det, du har set indtil videre, skal du fortsætte med at læse! Husk, at når du lærer dette en gang, vil det være super nemt i fremtiden, så det er bestemt værd at investere i tid. Vi ses i næste afsnit!

Main Indholdsfortegnelse Klik her Del A: Indledende opsætning Del B: kernefunktionaliteten Del C: Sidste trin til Full FledgedThese metoder blev delvist brugt i udbredelsen af renthero.ca