AWS-Amplifyの中身、とくにAuth

amazon-cognito-identity-jsに強く依存.

signIn()内でcreateCognitoUserしてる。createCognitoUserはCognitoUser()のラッパー。

    public signIn(username: string, password: string): Promise<any> {
        ...  
        const user = this.createCognitoUser(username);
        const authDetails = new AuthenticationDetails({
            Username: username,
            Password: password
        });

        const that = this;
        return new Promise((resolve, reject) => {
            user.authenticateUser(authDetails, {

createCognitoUserメソッドの元クラス (AuthClass) がuserPool属性を持っていて、この中にclientオブジェクトがしまってある。 Auth.configureでCognitoUserPool (amazon-cognito-identity-js由来) を使ってusePoolを設定してるので、おそらくここで一意に決まってくる。
Auth.configure(config)のconfigに入っているものがまんま使われており、この中にendpointがある模様。Amplifyチェック！

    private createCognitoUser(username: string): Cognito.CognitoUser {
        const userData: ICognitoUserData = {
            Username: username,
            Pool: this.userPool,
        };
        ...
        return new CognitoUser(userData);
    }

CognitoUserコンストラクタでdataを引数にとり、そこでthis.client (Clientクラス) にdata.Pool.clientを設定。

export default class CognitoUser {
  constructor(data) {
    ...
    this.username = data.Username || '';
    this.pool = data.Pool;
    this.Session = null;

    this.client = data.Pool.client;

Clientのコンストラクタでendpointを受け取って、以降は一切いじらない。nullの場合はcognito-idp...のドメインになる。
client.requestのリクエスト先ドメインはここで決まる。

// Facet.ts
import * as Cognito from 'amazon-cognito-identity-js';

// /src/Common/index.ts
export * from './Facet';

// /src/Auth/Auth.ts
import {
    AWS,
    Cognito,
    ...,
} from '../Common';

リクエスト実体
// @param {CognitoUserPool} data.Pool

this.client = data.Pool.client;

import Client from './Client';
CognitoUserPoolコンストラクタ内
this.client = new Client(region, endpoint);

client.requestはシンプルなfetch()
aws-amplify/Client.js at master · aws/aws-amplify · GitHub

パスワードでのダイレクト認証はメインとも限らない
authenticateUserDefaultAuthが色々やってて面白い
InitiateAuthリクエストをして、
RespondToAuthChallengeリクエストして、

ドキュメントにもそうある。

最新の認証フローはユーザーのアイデンティティを検証するため、パスワードの他に新しいチャレンジタイプを組み込んでいます。当社では 2 つの一般的なステップで認証を定型化し、InitiateAuth と RespondToAuthChallenge という 2 つの API を使用して実装します。

Secure Remote Password (SRP) プロトコル
パスワードから生成した何かで認証するプロトコル
パスワードが通信路に流れないのでセキュア

SRP 計算を回避する場合にセキュアなバックエンドサーバーで使用できるように設計された管理 API の代替セットもあります。

SRPうんぬんはまさに認証なので、OIDCがスコープ外にしてる認証部分なんだろう
つまりUserPools-IdPの認証部分。
でもこれ、クライアントの仕事…？
あ、わかった。
組み込みUIってこの部分が担当だろ
つまりホントのホントの認証部分にも当然、認証クライアントが必要なのでそこの話だ
2FAを組み込んだり色々有り得るから、一般化された内容になってると。おー。

UserPool-IdPでUserPools認証する場合、OIDC AuthNリクエストは走るのかな？
resにクライアントがパスワードぶち込んですぐ認証的な

• ベース: https://(mydomain).auth.(region).amazoncognito.com
  • 認可エンドポイント: /oauth2/authorize
  • トークンエンドポイント : /oauth2/token
  • ログインエンドポイント : /login
  • ログアウトエンドポイント : /logout