台灣的Web工程師

Cognito（使用者管理）

　　這一篇要說明的是一個AWS Cognito的系統，這個系統的功能主要是：

跟系統使用者有關的部份（這裡的系統指的是我們要實作的系統，而不是AWS的系統）

這個Cognito幫我們把所有跟使用者有關的後台部份都完成好了，包含使用者註冊、登入、忘記密碼、email認證、簡訊認證...，反正只要跟使用者有關係的，基本上他都幫我們想好了，我們只需要透過API的方式與Cognito串接即可；所以，如果今天我們懶得去實作我們的使用者管理系統的話，我們可以直接借助Cognito的協助，請他幫我們管理使用者。

Cognito的影響與迷思

　　在使用Cognito前，因為我們遇到了與之前實作的系統不太一樣的地方，所以會有幾件事的理解與考慮也與之前不太一樣，而這些部份也會影響到我們使用Cognito的意願，下方會將一些迷思列出來，我們要使用前必須先瞭解這個部份，而且最重要的是，讓擁有專案決定權的人瞭解這些。

1. User資料不存在我們的DB，這樣安全嗎？

使用Cognito時，使用者註冊後的資料是存放在Cognito裡面，所以可能有人會覺得不安全，這個論點也算是有根據的，因為跟DB比起來，Cognito是透過幾組特定的Key（pool key、client key）來對外開放，所以比起將DB放在後端，只開放特定機台連線的方式比起來，安全性當然比較低一點；不過換句話說，當我們的Cognito被破解的話，會流出的資料也只有使用者資料，主要的商業機密因為還是在我們DB，所以有影響。以這個層面來說，認真地去思考一下，你認為會有駭客用力的去破解這二組key，只為了得到一堆沒有密碼的使用者資料嗎？如果真的有這種事發生的話，這駭客不是內部的人的話，也只能說你人緣不好了。

不過視專案的安全性而定，有些人會無法接受使用者的資料不存在自己系統的DB中，如果是這樣的話，那就請放棄Cognito吧。

2. 因為User資料不存在DB中，所以也沒有Foreign Key。

我們都知道很多功能是建立在使用者資料上的，所以當DB不存在使用者資料時，就會產生這樣的問題，在這種情況下，筆者會建議在原本要存放user_id的欄位中，改儲放username，因為username（帳號）在Cognito中也必須是唯一。

這也是使用Cognito後會遇到的問題，這種狀況在筆者的眼中，不覺得是個問題，不過畢竟會遇到這樣的事，所以要使用Cognito時，請把這件事也考慮進來。

3. 使用者登入是透過我們的程式呼叫Cognito的API，所以程式端會拿到使用者登入密碼的明碼。

針這個問題，我只能說提出這個問題的人中了框架（Framework）的毒太深了。要知道，不管是那一個系統，只要是我們自己寫的程式，我們一定有辦法拿到未編碼前的密碼，這樣才能編碼後與DB的密碼欄比對，只不過很多情況下是由框架（Framework）幫我們處理掉，只不過現在是由我們自己動手做，差別只有這樣，並不是不使用Cognito的話，程式端就不會拿到明碼。

如果你認為上述幾點都不是問題的話，那我們就可以接下去使用Cognito了。

Cognito的免費額度與收費

基本上Cognito的計費方式只有一種，就是MAU（Month active user），MAU的意思是：每個月，每一次使用者與Cognito的互動，例如：登入、註冊...等等；MAU有點難理解，我們可以自行轉換為Request，也就是一個單位的MAU＝一次有效的Request，而MAU的免費額度是50,000 (MAU)，這個免費額度並不會因為12個月而到期，詳細可參考官網。

另外，我們在官網中也會看到一個「Cognito Sync」的收費標準，這個部份是Cognito的另一個功能，在本篇不會做介紹，所以讀者可以直接跳過。

使用Cognito

接下來我們就要開始使用Cognito了，首先先在AWS Console中找到Cognito：

選擇後進入，即會看到如下畫面：

Cognito中有二個主要的功能，一個是我們上述談論的，儲存使用者資料的地方，就是左邊的「User Pools」，而右邊的「Identities」的功能是：讓各方的系統使用者，可以透過這個功能來存取我們AWS帳戶下的AWS資源，這個功能才會有剛剛收費方式中提到的「Cognito Sync」費用。本篇介紹的只有「User Pools」的功能而已，所以我們就進入這個「User Pools」吧。

建立User Pool

一開始別放了選確認區域（Region），進入Cognito後，先找到「Create User Pool」的按鈕按下吧。

之後會看到這樣的畫面：

在這裡決定好我們的User Pool的name，這個name是給我們識別用的，實際上程式讀取的會是另外一個Pool key之類的編碼，所以這個name不用怕會跟其他人重覆，決定好name之後，在下方有二個按鈕，左方的是直接使用AWS的預設來建立Pool，右邊的按鈕是我們一步一步來完成整個設定，在這裡我們就選擇右邊，一步一步來看這個User Pool有什麼東西可以設定吧。

在第二步的「Attribute」中，可以看到畫面中Cognito已經幫我們建立好一些使用者該有的Attribute了，而第二列的「Require」代表這個使用者在註冊時有那些欄位是必填，這邊有一點要注意的事，必填欄位只有要在可以修改，建立User Pool後是無法修改的；第三列的Alias則是使用者登入的帳號欄位，如果都沒有勾選的話，會以username當做使用者登入的帳號。如果覺得這些欄位不符合我們的功能需求，下方也有增加Attribute的功能按鈕，設定完後就進入下一步吧；進入到下一步後，這裡總共有三個標題，我們一個一個來解釋：

這邊是設定密碼的部份，包含密碼的長度限制，密碼是否要包含數字、特殊符號、大寫、小寫等選項。

這裡設定你的系統是否允許使用者自行註冊，預設是可以設使用者自行註冊，否則你的程式必須先登入administrator的帳號後，再透過建立使用者的API來創建使用者。

最後是設定被管理員建立的帳號如果多久沒有使用，就讓這個帳號過期，這個設定並不會影響非管理員建立的帳號，也就是使用者自行註冊的帳號；這些設定完後，我們再來看下一頁。

這一頁一樣有三個標題，我們一個一個來看，不過在看內容之前，有一個關鍵字叫MFA（Multi-Factor Authentication），MFA的簡單來說就是多方檢證的意思，它實際應用的部份就是：

寄mail或簡訊給你，要求你輸入mail或簡訊上的認證碼，籍此來確認使用者輸入的mail或手機的正確性。

這個部份Cognito都幫我們實作完成了，我們只需要打勾這個選項，另外就支付簡訊或寄Mail的費用，就可以做到這件事了，畫面中的黃色小框框，也是提醒我們使用MFA可能會有費用發生，所以請自行斟酌。

當我們設定了MFA的話，目前MFA只支援手機或Mail的正確認，所以只有二個選項可以選擇，看我們是否需要驗証手機或Mail。

AWS有將寄發簡訊（SNS）或Mail（SES）的服務獨立出來，如果我們有使用MFA的話，會需要有一個角色有權限觸發SNS或SES，所以這裡必須指定一個這樣的角色，完成後進入下一頁的設定。

這一頁很簡單，主要是設定MFA的內容，比較特殊的是，最下方有一個「customize your email address」的功能：

因為Cognito使用者寄信服務是SES，你可以先設定好SES後，來這個選項要求Cognito使用我們設定好的SES，否則也可以請Cognito全權處理，為了省掉麻煩事，我們當然是請Cognito全權處理。

這一頁沒什麼好解釋了，就只是單純的Tag。

這一頁的描述是說是否要記住使用者的登入裝置，不過詳細的使用方式，筆者也沒有試過，所以先選擇「No」來跳過。

這一頁蠻重要的，因為通常使用者不會直接跟Cognito連線，而是透過我們程式API來與Cognito來做連結，而我們的API要與Cognito連線的話，就需要在這個頁面做一些設定，完成後要記得要先按「Create app client」後再進到下一頁。

最後再按一下「Create pool」即可建立。

Cognito的API

　　建立好Cognito的User pool後，我們就可以利用它來管理使用者的帳號了，不過，不可能利用人工去管理，一定是利用API的方式，所以我們必須使用Cognito提供的API來進行相應的處理，基本上Cognito有提供各種程式語言的API，上網找一下資料即可開始寫程式了，這個是Cognito的SignUp (註冊)的用法，而程式中會有到的參數ClientId及 SecretHash，還記得我們剛剛建立的App Clinet嗎？用建立好的ClinetId及SecretHash就可以進行連線了。

這裡還有一篇程式面向的文章，從註冊到登入，都教你怎麼呼叫了。

登入與JWT Token

透過API的方式進行使用者的登入時，Cognito會回傳一串JSON，JSON包含了三個物件，而這三個物件都是JWT Token，相關的文件在AWS官網中，所以登入成功後會拿到三個String：

• ID token：解開後主要會得到token_use的資料，也就是cognito的username。

• Access token：解開後除了得到username的資料外，連這個user相關的Attribute都可以拿到。

• Refresh token：當token過期後，需要Refresh用的。

結論

Cognito基本上就是一個使用者的管理系統，所以基本上與使用者相關的資料都存放在這邊，而因為Cognito回傳給我們的JWT Token並無對應的ID，所以我們的DB要存的Key word變成是使用者的帳號（Cognito中的唯一值），透過這個帳號再與DB做結合，取得相關的使用者資料，整個的用法是這樣的。不過「使用者」是很基礎網站功能，所以AWS推出這項服務，與其說是針對新建的網站，不如說是針對新型的Micro Server服務（例如搭配Lambda），不過要使用這個服務與否，還是得先過公司的決策者這一關，畢竟有些人對於資料不是存放在自己管控的情況下是抱有反感的。