Cross Application Authentication and API Handling
Need to run my ideas by everyone before getting too involved in trying to make it a reality. Apologies ahead of time for the wall of text but I am hoping it is all relevant to best explore my thought.
All applications will be written in Laravel at this point.
Background
I am been heavy focused on trying to create a central authentication application that I can use to log users into all of my first-party applications that will be getting created. I first tried with SAML and that works, but I am not 100% comfortable with the libraries I used nor with my knowledge of how SAML works to want to use it in production. Plus it seems way more work than is necessary to update certificates when they eventually expire.
So I turned my attention to OAuth. I have already built a basic Identity platform that I use Socialite on to log my users in, but now it is time to build that first first-party application and I'm exploring my options. I am not trying to implement a full SSO where you login once and then are logged in on all my other apps automatically, although I would like to implement something in the future to handle that if possible.
Secondly, I am working on a central API endpoint to handle all third-party API calls when that is eventually ready.
Rundown
- identity.company.com - This is the user profile application and will handle MFA and logging users in
- api.company.com - Used by third party developers
- shop.company.com - A first party app
- app2.com - Another first party app
- app3.com - etc
Authentication
Installing Passport on the identity application, using authorization grant type and a modified flow that removes the need for a consent screen for my first-party applications seems like it would be the best way to go. I would then use Socialite with a custom built provider to authenticate with the Passport install on the identity application, save the access token and refresh token and use those whenever I need to access data on the user profile.
Besides knowing if this is a good idea, I am not yet sure how to modify the consent screen to only show if a "is_first_party" column is true in the database so any hints as to what to override would be much appreciated.
Enabling a Third-Party API Platform
Each app would have Passport installed and use the client credentials grant to communicate with each other. This may be a stupid idea but I'd still like the input. My plan is to then have api.company.com use Passport as well but serve as a traditional OAuth server, using authorization grant type with a consent screen as normal. After third-parties get a token for api, the application would actually use the client credentials communication to pull data from the relevant applications.
I imagine the flow would be like this:
- Third-party (TP) registers for a client_id and client_secret from my api.company.com application
- TP would then do their development and launch their service
- Users would go to sign in on my platform, first hit the passport authentication on api
- Assuming the user isn't already logged in and approved, API would redirect to identity to do the authentication and get data about the user
- Identity would send the access token to API and API would save this data
- API would then display a consent screen for the TP app and upon approval finally be able to access user data via API.company.com endpoints
This allows me to have a single API for third-parties to utilize rather than one per application, especially when it comes to third-parties needing to pull some data from multiple apps (like identity and order information from the shop for example). Secondly, the API server can go down and not affect my own applications (if I was to use my own API endpoint for example instead of using client credentials).
Honestly, I can imagine I may be duplicating a bunch of API work on the individual apps as well as the master api application but in the long run I feel it would be worth it from a UX point of view for third-party developers.
Conclusion
So there you have it, my probably overly complicated plan. I would appreciate any feedback this community would have to offer and appreciate you sticking around if you are reading this :)
Please or to participate in this conversation.