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吧。

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

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

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

  1. 使用者登入是透過我們的程式呼叫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),不過要使用這個服務與否,還是得先過公司的決策者這一關,畢竟有些人對於資料不是存放在自己管控的情況下是抱有反感的。

arrow
arrow

    JAVA Programmer 發表在 痞客邦 留言(0) 人氣()