Is Multi Authentication on one Endpoint Considered Bad Practice?

Whilst this question is arguably opinion based, I am looking to gauge the opinions of other engineers on this matter in order to assist in settling a debate between two engineers.

Consider the following:

Mobile Application

• All users the same (i.e. no roles/permissions)
• Users sign in with Phone Authentication (same as Whatsapp) i.e. NOT email/password

Admin Web Portal

• Administrators are entirely separate users to those in the Mobile Application i.e. if a user of the App happens to also work for the company, they will have to have a separate account created for the admin portal
• Administrators login using email/password

Both of the above should (feel free to disagree) consume the same API in order to prevent duplication of the business logic etc. However, should the administrators be kept in an entirely separate table, and should both applications have different authentication endpoints provided by the same API?

Option 1

Due to the logic behind both authentications being entirely different, and the fact that both user models will also be completely different, I would have done the following:

• Separate tables for administrators and users
• Completely separate authentication endpoints for administrators and users (see below)

Application User

• Create SMS Request: POST /auth/requests
• Verify SMS and Authenticate: POST /auth

Administrator

• Authenticate: POST /admin/auth

Alternatively, I would just create the Admin Portal API as a completely separate API - although, the downside of this is that there will be two places required to maintain the business logic.

Option 2

An alternative method has been suggested that, personally, I am really against. However, I am very open to having my mind changed if anyone can persuade me it is not 'bad practice', and it is better than what I have outlined in option 1.

• One table for users - this contains app users, and administrators, despite them having different models

• One authentication flow that caters to both the app users, and the admin portal (see below)

• Create SMS Request / Login (dependant on supplied parameters i.e. phone number, or email and password): POST /auth - this returns a JWT token before the phone is even verified, but the JWT token is restricted to only access the following endpoint

• Verify SMS: POST /users/verification - not needed for those that login with email and password

Which option do you believe is better, or is there an even better way to solve this problem?