[AWS] Amazon Cognito

看懂 [AWS] User management and [AWS] OAuth2.0 才方便看到此篇。

Ref: 常見 Amazon Cognito 場景

Amazon Cognito 的兩個主要組件是用戶池和身份池。

• 用戶池：是為您的應用程序提供注冊和登錄選項的用戶目錄。
• 身份池：提供 AWS 憑證以向用戶授予對其他 AWS 服務的訪問權限。 

 

1. 在第一步中，您的應用程序用戶通過用戶池登錄，並在成功進行身份驗證后收到持有者令牌。[access token, id token, refresh token]

2. 接下來，您的應用程序通過身份池用用戶池令牌交換 AWS 憑證。

3. 最后，您的應用程序用戶可以使用這些 AWS 憑證 來訪問其他 AWS 服務 (如 Amazon S3 或 DynamoDB)。

 

使用用戶池進行身份驗證

Figure, 標准化推薦訪問驗證

 

您可以允許您的用戶使用用戶池進行身份驗證。

您的用戶可以通過用戶池直接登錄，

也可以通過第三方身份提供商 (IdP) 間接登錄。

 

用戶池管理處理以下令牌的開銷：

從通過 Facebook、Google 和 Amazon 進行的社交登錄返回的令牌，

以及從提供單點登錄解決方案 (如 Microsoft Active Directory Federation Services (ADFS)) 的 SAML 身份提供商返回的令牌。

 

成功進行身份驗證后，您的 Web 或移動應用程序將收到來自 Amazon Cognito 的持有者令牌。

您可以使用這些令牌檢索允許您的應用程序訪問其他 AWS 服務的 AWS 憑證，

也可以選擇使用它們來控制對您自己的資源或 Amazon API Gateway 的訪問。

 

使用用戶池訪問您自己的資源

您可以允許您的用戶使用來自成功的、身份驗證的、用戶池令牌訪問您自己的資源。

有關更多信息，請參閱 用戶池身份驗證流程 和 將令牌與用戶池結合使用。

Figure, 訪問自己的資源

 

用戶池身份驗證流程

• • 客戶端身份驗證流程
  • 服務器身份驗證流程
  • 自定義身份驗證流程     ----> 三大令牌
  • 管理員身份驗證流程
  • 用戶遷移身份驗證流程

 

將令牌與用戶池結合使用

成功進行身份驗證后，您的 Web 或移動應用程序將收到來自 Amazon Cognito 的持有者令牌。

以下是由 OpenID Connect 規范定義的令牌：

• ID 令牌

• 訪問令牌

• 刷新令牌

 

 

使用 ID 令牌

ID 令牌以 JSON Web Token (JWT) 表示。

該令牌包含有關已驗證用戶的身份的聲明。

例如，它包含 name、family_name、phone_number 等聲明。

 

有關標准聲明的更多信息，請參閱 OpenID Connect 規范。客戶端應用程序可以在應用程序中使用此身份信息。

此外，ID 令牌還可用於針對資源服務器或服務器應用程序對用戶進行身份驗證。

在應用程序外部將 ID 令牌用於 Web API 時，您必須先驗證 ID 令牌的簽名，然后才能信任 ID 令牌內的任何聲明。

ID 令牌會在用戶進行身份驗證后的 1 小時內過期。在 ID 令牌過期后，您不應該在客戶端或 Web API 中對其進行處理。

 

使用 ACCESS 令牌

訪問令牌也以 JSON Web Token (JWT) 表示。它也包含有關已驗證用戶的聲明，但與 ID 令牌不同，它不包含用戶的所有身份信息。

訪問令牌的主要用途是在用戶池中用戶的環境中授予操作權限。

例如，您可以根據用戶池使用訪問令牌更新或刪除用戶屬性。

 

此外，訪問令牌還可與任何 Web API 結合使用，以做出訪問控制決策並在用戶環境中授予操作權限。

與 ID 令牌一樣，您必須先在 Web API 中驗證訪問令牌的簽名，然后才能信任訪問令牌內的任何聲明。

訪問令牌會在用戶進行身份驗證后的 1 小時內過期。在訪問令牌過期后，您不應該對其進行處理。

 

使用刷新令牌

要使用刷新令牌獲取新令牌，請使用 InitiateAuth 或 AdminInitiateAuth API 方法。驗證流程類型為 REFRESH_TOKEN_AUTH。授權參數 AuthParameters 是密鑰-值映射，其中密鑰為“REFRESH_TOKEN”，值為實際刷新令牌。

這會通過 Amazon Cognito 服務器啟動令牌刷新流程並返回新的 ID 和訪問令牌。

默認情況下，刷新令牌會在用戶進行身份驗證后的 30 天內過期。當您為用戶池創建應用程序時，您可以將應用程序的 Refresh token expiration (days) 設置為介於 1 和 3650 之間的任何值。

 

 

 

問題來了，如何讓另一個獨立的服務納入到現有的用戶認證系統中來？ 

---

AWS 提供的單點登錄(SSO)

 

這里實際出現了問題，兩個端口需要一個統一的http server來分流，統一作為“前台”接待用戶。

在此項目中不適合。

SSO討論到此為止。 

 

 

 

AWS Amplify才是未來

---

Goto：Quick Start

 

安裝amplify：

$ npm install --save aws-amplify

# On a React app, in addition to aws-amplify, 
# we provide helpers and higher order components that are packaged in aws-amplify-react.

$ npm install --save aws-amplify-react # optional HOCs

 

 

概念理解：

AWS Mobile Hub：AWS Amplify connects to AWS Mobile Hub to work with Amazon Web Services.

AWS Mobile CLI：creates and configures new AWS resources for your backend.

$ npm install -g awsmobile-cli

# 第一次使用，則：
# To setup permissions for the toolchain used by the CLI, run:

$ awsmobile configure

onfigure aws
? accessKeyId:      <YOUR_ACCESS_KEY_ID>
? secretAccessKey:  <YOUR_SECRET_ACCESS_KEY> 

為何要有accesskeyId and secretAccesskey? It seems like something for S3.

 

 

配置后端

自動配置 - 暫時不關心

手動配置 - 令人放心

Manual Setup to work with existing AWS Resources

If you want to use your existing AWS resources with your app (S3 buckets, Cognito user pools, etc.),

you need to manually configure your app with your existing credentials in your code:

就是配置最常用的一些aws服務：https://serverless-stack.com/chapters/configure-aws-amplify.html

Amplify.configure({

  Auth: {
    mandatorySignIn: true,
    region: config.cognito.REGION,
    userPoolId: config.cognito.USER_POOL_ID,
    identityPoolId: config.cognito.IDENTITY_POOL_ID,
    userPoolWebClientId: config.cognito.APP_CLIENT_ID
  },
  Storage: {
    region: config.s3.REGION,
    bucket: config.s3.BUCKET,
    identityPoolId: config.cognito.IDENTITY_POOL_ID
  },
  API: {
    endpoints: [
      {
        name: "notes",
        endpoint: config.apiGateway.URL,
        region: config.apiGateway.REGION
      },
    ]
  }
});

 

 

Add User Authentication to Your App

Goto: https://aws.github.io/aws-amplify/media/authentication_guide

 

Automated Setup - 不放心

Manual Setup - 推薦

第一階段效果：

URL: https://dha4w82d62smt.cloudfront.net/items/2R3r0P453o2s2c2f3W2O/Screen%20Recording%202018-02-11%20at%2003.48%20PM.gif

 

 

 

[AWS] OAuth2.0

---

 

Ref: 理解OAuth 2.0

若干專有名詞：

（1）Third-party application：第三方應用程序，本文中又稱"客戶端"（client），即上一節例子中的"雲沖印"。

（2）HTTP service：                HTTP服務提供商，本文中簡稱"服務提供商"，即上一節例子中的Google。

（3）Resource Owner：          資源所有者，本文中又稱"用戶"（user）。

（4）User Agent：                   用戶代理，本文中就是指 瀏覽器。

（5）Authorization server：   認證服務器，即服務提供商專門用來處理認證的服務器。

（6）Resource server：          資源服務器，即服務提供商存放用戶生成的資源的服務器。它與認證服務器，可以是同一台服務器，也可以是不同的服務器。

 

上圖第三步中的“授權”，可以是，比如“授權碼” + “重定向URI”。

 

（A）用戶打開客戶端以后，客戶端要求用戶給予授權。
（B）用戶同意給予客戶端授權。　　# 最為重要 --> 詳解
（C）客戶端使用上一步獲得的授權，向認證服務器申請令牌。
（D）認證服務器對客戶端進行認證以后，確認無誤，同意發放令牌。
（E）客戶端使用令牌，向資源服務器申請獲取資源。
（F）資源服務器確認令牌無誤，同意向客戶端開放資源。

 

 

客戶端必須得到用戶的授權（authorization grant），才能獲得令牌（access token）。

OAuth 2.0定義了四種授權方式。

• 授權碼模式（authorization code）    # 功能最完整、流程最嚴密的授權模式
• 簡化模式    （implicit）
• 密碼模式    （resource owner password credentials）
• 客戶端模式（client credentials）

 

 

資源服務器如何辨別令牌的真假?

因為有一步可能是在客戶端的后端的服務器上完成的，對用戶不可見。詳情如下：

 

授權碼模式

 

 

（A）用戶訪問客戶端，后者將前者導向認證服務器。客戶端申請認證的URI，包含以下參數：

• • response_type：表示授權類型，必選項，此處的值固定為"code"
  • client_id：    表示客戶端的ID，必選項
  • redirect_uri： 表示重定向URI，可選項
  • scope：        表示申請的權限范圍，可選項
  • state：        表示客戶端的當前狀態，可以指定任意值，認證服務器會原封不動地返回這個值。

         GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
                 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
 Host: server.example.com

（B）用戶選擇是否給予客戶端授權。
（C）假設用戶給予授權，認證服務器將用戶導向客戶端事先指定的"重定向URI"（redirection URI），同時附上一個授權碼。回應URI：

• • code： 表示授權碼，必選項。

                  該碼的有效期應該很短，通常設為10分鍾，客戶端只能使用該碼一次，否則會被授權服務器拒絕。

                  該碼與客戶端ID和重定向URI，是一一對應關系。

• • state：如果客戶端的請求中包含這個參數，認證服務器的回應也必須一模一樣包含這個參數。

         HTTP/1.1 302 Found
 Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA &state=xyz

（D）客戶端收到授權碼，附上早先的"重定向URI"，向認證服務器申請令牌。這一步是在客戶端的后台的服務器上完成的，對用戶不可見。

• • grant_type：  表示使用的授權模式，必選項，此處的值固定為"authorization_code"。
  • code：        表示上一步獲得的授權碼，必選項。
  • redirect_uri：表示重定向URI，必選項，且必須與A步驟中的該參數值保持一致。
  • client_id：   表示客戶端ID，必選項。

        POST /token HTTP/1.1
 Host: server.example.com  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW  Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

（E）認證服務器核對了授權碼和重定向URI，確認無誤后，向客戶端發送訪問令牌（access token）和更新令牌（refresh token）。

• • access_token： 表示訪問令牌，必選項。
  • token_type：   表示令牌類型，該值大小寫不敏感，必選項，可以是bearer類型或mac類型。
  • expires_in：   表示過期時間，單位為秒。如果省略該參數，必須其他方式設置過期時間。
  • refresh_token：表示更新令牌，用來獲取下一次的訪問令牌，可選項。
  • scope：        表示權限范圍，如果與客戶端申請的范圍一致，此項可省略。 

        HTTP/1.1 200 OK
        Content-Type: application/json;charset=UTF-8
        Cache-Control: no-store
        Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }

 

 

簡化模式

簡化模式（implicit grant type）不通過第三方應用程序的服務器，直接在瀏覽器中向認證服務器申請令牌，

跳過了"授權碼"這個步驟，因此得名。所有步驟在瀏覽器中完成，令牌對訪問者是可見的，且客戶端不需要認證。 

 

（A）客戶端將用戶導向認證服務器。

• • response_type：表示授權類型，此處的值固定為"token"，必選項。
  • client_id：    表示客戶端的ID，必選項。
  • redirect_uri： 表示重定向的URI，可選項。
  • scope：        表示權限范圍，可選項。
  • state：        表示客戶端的當前狀態，可以指定任意值，認證服務器會原封不動地返回這個值。

        GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
            &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
        Host: server.example.com

（B）用戶決定是否給於客戶端授權。
（C）假設用戶給予授權，認證服務器將用戶導向客戶端指定的"重定向URI"，並在URI的Hash部分包含了訪問令牌。
    [簡化去掉了“授權碼”，直接獲得了隱藏在hash值中的令牌，瀏覽器此時沒法提取令牌]

• • access_token：表示訪問令牌，必選項。
  • token_type：  表示令牌類型，該值大小寫不敏感，必選項。
  • expires_in：  表示過期時間，單位為秒。如果省略該參數，必須其他方式設置過期時間。
  • scope：       表示權限范圍，如果與客戶端申請的范圍一致，此項可省略。
  • state：       如果客戶端的請求中包含這個參數，認證服務器的回應也必須一模一樣包含這個參數。

         HTTP/1.1 302 Found
         Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
                   &state=xyz&token_type=example&expires_in=3600

（D）瀏覽器向資源服務器發出請求，其中不包括上一步收到的Hash值。 
（E）資源服務器返回一個網頁，其中包含的代碼可以獲取Hash值中的令牌。 
（F）瀏覽器執行上一步獲得的腳本，提取出令牌。 
（G）瀏覽器將令牌發給客戶端。

 

 

密碼模式

在這種模式中，用戶必須把自己的密碼給客戶端，但是客戶端不得儲存密碼。

這通常用在用戶對客戶端高度信任的情況下，比如客戶端是操作系統的一部分，或者由一個著名公司出品。

而認證服務器只有在其他授權模式無法執行的情況下，才能考慮使用這種模式。 

 

整個過程中，客戶端不得保存用戶的密碼。

（A）用戶向客戶端提供用戶名和密碼。

（B）客戶端將用戶名和密碼發給認證服務器，向后者請求令牌。

• • grant_type：表示授權類型，此處的值固定為"password"，必選項。
  • username：  表示用戶名，必選項。
  • password：  表示用戶的密碼，必選項。
  • scope：     表示權限范圍，可選項。 

         POST /token HTTP/1.1
         Host: server.example.com
         Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
         Content-Type: application/x-www-form-urlencoded

         grant_type=password&username=johndoe&password=A3ddj3w

（C）認證服務器確認無誤后，向客戶端提供訪問令牌。

     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }

 

 

客戶端模式

客戶端模式（Client Credentials Grant）指客戶端以自己的名義，而不是以用戶的名義，向"服務提供商"進行認證。

嚴格地說，客戶端模式並不屬於OAuth框架所要解決的問題。

在這種模式中，用戶直接向客戶端注冊，客戶端以自己的名義要求"服務提供商"提供服務，其實不存在授權問題。

 

（A）客戶端向認證服務器進行身份認證，並要求一個訪問令牌。客戶端發出的HTTP請求，包含以下參數：

• • granttype：表示授權類型，此處的值固定為"clientcredentials"，必選項。
  • scope：表示權限范圍，可選項。

        POST /token HTTP/1.1
        Host: server.example.com
        Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
        Content-Type: application/x-www-form-urlencoded

        grant_type=client_credentials

（B）認證服務器確認無誤后，向客戶端提供訪問令牌。

       HTTP/1.1 200 OK
       Content-Type: application/json;charset=UTF-8
       Cache-Control: no-store
       Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "example_parameter":"example_value" } 

 

 

更新令牌

如果用戶訪問的時候，客戶端的"訪問令牌"已經過期，則需要使用"更新令牌"申請一個新的訪問令牌。

客戶端發出更新令牌的HTTP請求，包含以下參數：

granttype：    表示使用的授權模式，此處的值固定為"refreshtoken"，必選項。
refresh_token：表示早前收到的更新令牌，必選項。
scope：        表示申請的授權范圍，不可以超出上一次申請的范圍，如果省略該參數，則表示與上一次一致

下面是一個例子。

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA