Using Passport and/or Sanctum to Authenticate a Mobile App and a Separate Web App

@vincent15000 I'm not opposed to using Sanctum as my solution, though I'm not sure how I would handle user authentication from a separate Laravel application, or how I would then tie user profile data to the account in a different database.

@empko The simplest way is to use an API token. But if you use a third party authentication service, you don't need Sanctum anymore.

@vincent15000 An API Token from Sanctum may help with the mobile app, but I don't see how it would be of any use when trying to handle user data from a different application on a different domain and database. The two applications I am working on are tangentially related, hence the desire to use a single sign on between the two, but the data one application stores is unrelated to the other, and vice versa.

@empko The authentication with a token doesn't depend on the domain or the database.

Once the token is created, you have to send it to the frontend and the frontend will send it back with each request to the server.

Then the application will check for the token validity and if it's valid, you can use the controllers.

You can protect your routes with a middleware to check if the token is valid.

@vincent15000 But how would the app know if a token is valid, and that it is for the correct user, if the actual email and password for that user exists in a different application/database? And how would I create relations between that user and some other model if the two are in different databases? That is the part I am having trouble with.

@empko The token can be stored in on of the databases for example.

But for the relations between two tables from two different databases, you won't be able to use the relationships in the models.

@martinbean If I do use Passport to make the central auth server, would I then integrate something like Sanctum on the mobile app API server to handle all future authentication questions? After doing some further research, the flow I have found that seems intuitive would be:

1. Auth against central Passport server
2. return token to mobile app
3. send token to API server
4. Verify token against Passport server using Socialite
5. Send back Sanctum API token

Whereas the web app would just auth using Socialite directly. Does that all seem like the appropriate way to handle a situation like this?

@empko You use either Passport or Sanctum, but not both at the same time.

I'm not looking to have Sanctum and Passport on the same app. I would have three apps total, auth.app, web.app, and api.app.

Passport would be installed on auth.app, Sanctum would be installed on api.app, and Socialite would be installed on both web.app and api.app.

The mobile app users would first login against auth.app and receive a token. The app would then send this token to api.app, which would verify if it is valid using Socialite, and if it is, send the mobile app a Sanctum token.

The web app users would just login against auth.app making use of Socialite.

I'm just trying to make sure that I can deploy a proper single sign on auth solution for my client, ideally while remaining secure.

If I do use Passport to make the central auth server, would I then integrate something like Sanctum on the mobile app API server to handle all future authentication questions?

@empko No. Your mobile app opens a browser window to let the user authorise access to their account, and the user will then be redirected back to the app with an OAuth token.

@martinbean Right, but once they are authed against the central account server, how do I know which user to associate them with on the API server? In my mind, I would send the OAuth token to the API server, it would check validity using Socialite::getUserFromToken, then call Auth::login($user), generate a Sanctum token and send it back to the app to handle all further API requests. Or would it make more sense to just call Socialite::getUserFromToken on every API request?

Right, but once they are authed against the central account server, how do I know which user to associate them with on the API server?

@empko What do you mean? If you send the user to a “central” server to authenticate, then that’s who the user is. Otherwise what’s the point of a “central” server if your users are spread elsewhere?

Stop over-complicating things.

1. Use opens app.
2. User taps sign in button.
3. User is sent to authentication server to authorise.
4. If user logs in, then they’re sent back to the app with an OAuth token.
5. You know who the user is. Because you’ve just made them authenticate and now have a token for them.

@martinbean Maybe I'm not understanding things well, or explaining myself well. What I meant is that there is user-specific data for each app, things like profile information, comments, etc. that only make sense within their own app. I want to avoid putting this data in the central authentication server's database. On the web app, I can just use Socialite to handle authentication, and it should all just work.

My confusion comes from how to handle this on the mobile app. I understand that I should use a web page for the user to login, and send the OAuth token back to the app. From there though, how do I, in the API server, get all the data related to this user when I need to? In particular, this kind of relational data is integral to the majority of the functions of this app, and I would imagine having to do Socialite::getUserByToken on every API request would introduce unneeded complexity and latency. Because of that, my thought was to use Sanctum as a sort of "broker" for lack of a better term, where it takes over communications after Passport and Socialite have done their thing, allowing me to know which user's related data I need to be pulling from cache/db just by using the Sanctum token.

If just using Socialite::getUserByToken on every request is actually the proper way to handle this situation, then that's what I'll do. I just want to ensure that whatever I implement, it's going to work and remain stable in the long run.

I will also say this: I apologize if I'm being dense, stubborn, or otherwise having a hard time understanding. I've only been working in Laravel a couple years, and I've primarily been maintaining and improving legacy systems (Laravel 5). I've only just recently been given the opportunity to rebuild these systems, to bring them up to the latest versions of Laravel, with one of the requests for these rebuilt systems being a Single Sign-On system between them.