请求反馈：使用多个端点的多步 API 身份验证

Question

I am building an API that will authenticate using the following flow.

Endpoints:

• WWW:/login - this is the HTML5 frontend using JS ajax calls
• API:/check_password - checks email/password combo.
• API:/check_otp - checks OTP (One-time password) for user.
• API:/login - sets authentication session cookie

Assumption:

• API:/check_otp will always and only ever be called after API:/check_password .
• Ignore CSRF attacks and XSS attacks.
• Even if the frontend (WWW:/login) is malicious, the API will only work with valid credentials and/or action_tokens .
• I am aware of OAuth2, JWTs, and RESTful APIs. My question is not about RESTful API.

When logging in, the flow would be this:

• WWW:/login submits email and password to API:/check_password .

• If the credentials are valid, API:/check_password will return an action_token and mfa_status (stands for Multi-factor authentication).

  • If mfa_status is 0, that means MFA is not enabled.
  • If mfa_status is 1, that means MFA is enabled.

• If (mfa_status === 1) , then WWW:/login will call API:/check_otp and pass it the action_token received from API:/check_password as well as the OTP.

  • If the OTP and action_token are valid, then API:/check_otp will return a new action_token .
• If (mfa_status === 0) or API:/check_otp returns a valid action_token , then WWW:/login will call API:/login and pass to it the email and action_token .

To me, this means the frontend does NOT need to save the password or OTP anywhere in its data stores (localstorage, indexeddb, etc). It also means it can immediately remove the action_token from its data stores.

QUESTIONS:

1. Is this secure?
2. Are there any flaws in this logic?
3. Did I miss anything?

Many thanks for an interesting and thorough discussion!

Answer 1

Your pattern directly maps to OAuth2, why would you not use a tried-and-true security pattern like OAuth2? You are trying to rebuild it for some reason... your action_token is the same as the OAuth access token.

Also, you will need to keep your access token for subsequent calls to protected resources (you know like OAuth does)...

All you are doing is making more work for yourself by not either using an out-of-the-box OAuth library, or obfuscating the process to make the next person to update this code cranky with you.