Ok I’m about 2 weeks into my head first dive into AngularJS 2 and Laravel 5.3.
I’m approaching Angular JS 2 from 1, but going into Laravel pretty much from scratch (with prior PHP experience), so there were/are alot of new paradigms to get used to.
So far, it’s been pretty mind blowing on how easy it is to accomplish things, provided one gets the syntax and methodology correct. In both AngularJS2 and Laravel 5, one would notice that there is a lot more ‘setting up’ to do before one gets to coding a new feature, be it with a new controller or service. But it all works out well, because in the end, the code and data is more structured.
I was particularly impressed with how the Eloquent ORM system in Laravel, where I define my database table relationships, and simply let Laravel handle all relational calls from there. Mindblowing.
My social media app is coming along very well so far, with AngularJS 2 as the frontend, and Laravel 5 serving as the API and future backend management.
Now on to my problem. User Auth.
A classic user auth via login form is easy as pie with Laravel, however since I’m building an API, I need something different. Passport was supposed to be the answer, but apparently it is not, or not as easy as I thought it would be.
You see, Passport is meant to be a way for one to build an OAuth server in minutes.
An OAuth server however, is not quite simply a login mechanism. I mean, part of it IS providing a means for user to get authenticated (log in), but to put it in layman terms, it’s like building Pinterest just so I can find a way to upload my photos a website.
Passport in fact seems to be at it’s core, creating a separate OAuth server, for Clients/Consumers (which confuses me to be honest), for sake of simplicity, let’s refer to Client as Our App. So the Passport implementation would act as Facebook, when we’re using Facebook Connect to login to Our App, but let’s refer to it simply as Passport.
So, in reality, one would find a ‘Connect with Passport’ button on Our App.
The user clicks on that button, and gets redirected to Passport. If the user is logged in on Passport, they get a dialog asking for permission to share their info with Our App.
User clicks yes, and they are redirected back to Our App with the access tokens.
Our App processes and stores that token information to determine user is logged in.
This methodology works if we are trying to login from a 3rd party website with our Passport credentials.
Our App and Passport is in fact the same platform. We are not trying to Connect with Passport, we are trying to Login to Our App.
We need to implement our Auth as an API, without redirects and confirmation on a web page.
There are some comments on threads saying “That’s the whole purpose of OAuth! So you don’t have to login with username/password!”
That is a stupid statement, because OAuth works by using credentials that you already logged into in the Passport server. You only don’t need to log in on Our App. At some point in time, you ALWAYS have to do a username/password login somewhere, as the basis of your authenticated user.
Which simply means, that in this single server/app implementation, OAuth is completely irrelevant!
Question then is..
Can we leverage Passport to just perform login auth and create tokens?
Seems like the Generate Personal Token is the way? It generates a token based on the logged in user to use freely, without requiring any authentication. Are there any security concerns though?
Maybe not, looks like what we’re looking at is Consuming our own API
Consuming own API is simply setting the Web Requests on Laravel to always generate an api token in cookies, so requests are authenticated. API Requests first look for authorization headers, if they don’t exist, then it looks for the cookie token.
At this points, it looks like a combination of Generating Personal Token, AND enabling Consuming Own API.
I’ve also come across some people saying the answer is Grant Password.
Ok after a lot of thinking, I finally understood the paradigm.
I was right when I said it was kind of overkill to use the Laravel Passport as a login mechanism. That said, it is also easy to leverage it for use in a self owned frontend + api.
Here’s the process.
- Create Sign Up APIs, using the built in Laravel Auth Methods. Nothing to do with Passport here.
- The Login API is simply a call to the OAuth method to retrieve a Password Grant. The params for the password grant require username and password, which acts as the login as well. A successful auth will return the token to be used.
That, is fucking it.
Look, the other OAuth functionality is only if you want OTHER apps to use YOUR PLATFORM as a means of logging in. Not the other way round.
So if you were actually coding something called AngstyCoders.com , and make full use of Laravel Passport, Stack Overflow might one day have an option for people to Connect with AngstyCoders, which then is when you would fully utilise Laravel’s Passport OAuth features.