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
