Passport for Lumen

Wouldn't be hard to find out.

I don't see why not, judging from the dependency list: https://github.com/laravel/passport/blob/master/composer.json

Actually it doesn't work out of the box or at least routes injection (Passport::routes()) won't work - due to difference in routing.

Also, Passport relies on sessions which aren't available in Lumen.

I'm still playing around though, maybe I will find a workaround

Yeah, please let me know if you find a workaround!

Well, the main problem is Passport::routes() - as a quick workaround you could copy/paste it to your own class, replace $router with app() and remove web-related routes that require session (such as 'authorise' routes).

The rest seems to be ok. I will probably make a separate package for this, for convenience (of my own as well as the others)

Thanks, I'll give it a try. Although it would be pretty useless for many apps to use Passport Authentication without the ability to remember the user (with sessions)...

It seems to work fine for me so far - Passport is mostly compatible with Lumen.

Why would you need to remember the user? It's kind of against the whole idea of tokens, APIs and stateless auth? And Lumen removed sessions long time ago anyway.

If you want that web part where users can generate new tokens manually or authorise third-party applications - use Laravel with Passport. If you are implementing an API - use Lumen with Passport :)

I made a tiny package for this: https://github.com/dusterio/lumen-passport

One of my projects needs this so I'm going to maintain it properly (unless Taylor adds Lumen support in the official release)

That's great! But what if I want to use my Lumen API in a Vue application. There has to be a way to store the token for other api requests. And cookies are the most secure option...

I think I'll manually add the session component to Lumen.

@Jordy8 not sure if it's a good idea – serving Vue.js application from Lumen. Lumen doesn't even have the templates now, it's positioned as a clean API framework?

And if you are not serving Vue.js files from Lumen app, you can persist your sessions (cookies) there – at the point you serve Vue.js from.

In any case, it only makes sense that every request should be authenticated separately – that's how all world's APIs work.

For an spa with vue and lumen as two separate apps, lumen works amazingly well.

@dusterio, Shouldn't I set the cookie on first request at the server side (so on my Lumen API) and not at the client side (Vue)?

And what jekinney says: it's for a SPA, so I think Vue can perfectly interact with Lumen.

@jekinney if Vue is a separate app, that's where sessions/cookies can be kept @Jordy8 APIs unlike 'normal' websites don't set cookies

There is also this second option - local storage, you could keep the access token there React/Redux guys are doing it this way for instance: https://github.com/lynndylanhurley/redux-auth

But even if it's a cookie, it just shouldn't be on the API side, it should be somewhere else

Why don't you just use Laravel instead of Lumen?

Why are choices for the amount of backend services a bad thing? Lumen had much of the needed view support in 5.1 and it was removed in 5.2 so we could focus on micro-frameworks? Why not just configure your server side services? Zend express gives you great flexibility in what you want to use server side when you create a new project. Personally I have always been data based in how I build things. Front end code is just an interface delivered as an application like windows or HTML in a browser. Its all just resources and data and ways to transport it and store it. Cookies used to live in 'cookie jars' and were passed between objects between instances. None of this new or invented last week.

@dusterio

https://github.com/vuejs/vue-cli

Passport being o auth 2 it's against the pattern to store the keys/auth in a cookie. Just like any o auth, you send the keys in each request. That is your auth.

Jwt token works the same princable as the token is sent via a header on each request. You also have access to client side storage with JavaScript, useful to store the jwt token.

Not sure why cookies have to be used?

@dusterio, I use Lumen instead of Laravel because it will be an API, and Lumen is much more lightweight.

@jekinney, cookies have to be used to store the auth token so the user doesn't have to reauthenticate each time after closing his browser. You mention the client side storage, but that is vulnerable for XSS attacks. A better option is saving it in cookies (https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage). As @dusterio mentions, it is indeed true that API's shouldn't set cookies, so I think I have to handle this with Vue.

http://taha-sh.com/

Amazing articles!!!!

export default {
  user: {
    authenticated: false,
    profile: null
  },
  check () {
    if (localStorage.getItem('id_token') !== null) {
      Vue.http({
        url: 'user',
        method: 'GET'
      }).then(response => {
        this.user.authenticated = true
        this.user.profile = response.data.data
      })
    }
  },
});

Just horrible!!! The token has expiration time set server side, I hear what your saying though.

@jekinney, Yes, it's the same probleem indeed, and localStorage is vulnerable to XSS. Cookies would be better.

@Jordy8 cookies are vulnerable to another type of attack - CSRF

Check https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage for details

There is no perfect solution, but if you choose to store cookies - just don't store them in your API :))

The way I understand it is that Lumen is not meant to be used stand-alone, unless you want to build something free-for-all. Adding sessions and views defeats its purpose.

For a complete oAuth service, I would use a full Laravel installation with Passport to handle token creation and authorization, along with all the other front end stuff. And then use lumen just for the actual API routes, which would redirect the user to the full laravel for token creation etc.

The only thing missing is some package to shoehorn the passport middleware, guard and api driver into lumen.

@dimkasta You are saying 'actual API routes' and then 'redirect' - these two can never go together! API or AJAX calls cannot redirect user.

I still don't like the idea of the huge Laravel overhead if I just want an OAuth2 (identity) server. I don't want sophisticated template systems or sessions (they don't scale horizontally).

I'm starting an open source project shortly - an API gateway with built in authentication, based on Lumen and Laravel Passport.

@dusterio 'actual API routes' and then 'redirect' - these two can never go together! API or AJAX calls cannot redirect user.

True. My bad. The API only responds with its json or access denied or error. It just needs a way to check your token against your token implementation.

You also said, "I still don't like the idea of the huge Laravel overhead if I just want an OAuth2 (identity) server. I don't want sophisticated template systems or sessions (they don't scale horizontally)."

True. But I guess it will depend on the project if it is worth the effort to properly support a package to production security levels just to allow the user management parts to scale horizontally better than plain Laravel.

Again, by dropping sessions and views and providing just a placeholder for authentication, lumen basically declared that everything stateful and everything User Interface should be handled in another application. Anyway. I will follow this thread with great interest :)

And I am curious if Taylor will provide some middleware implementations for Passport backends or some other way to leverage third party ID providers like with socialite.

"And I am curious if Taylor will provide some middleware implementations for Passport backends or some other way to leverage third party ID providers like with socialite."

At least it is on his To-Do-List: https://twitter.com/taylorotwell/status/773634397589295104

Hi @dusterio

i was following steps given by you in https://github.com/dusterio/lumen-passport.

i stuck at place where it says i need to use trait in User model, the project on which i am working is already build and this project is using only controllers no model file is used, tables are directly used in controller. Now Please let me know how i can do this step. Second my user table has some different name, is it will affect passport integration.

Thanks

Hi @dusterio,

I am new in laravel/lumen and i was trying last 3 days to install your package lumen-passport. I am getting some errors.

On github you have description how to install lumen passport for version 1.7 but your latest lumen-passport version 1.9 has missing routes functions and that reason

Dusterio\LumenPassport\LumenPassport::routes($app); function are not working.

if i am not using LumenPassport::routes then I am getting very long response but i dont know is correct response

Array ( [response] => {"token_type":"Bearer","expires_in":31536000,"access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImp0aSI6IjYwMzAyMzcwN2Q2M2EwYjMwNGUyMTEwNzg1ZTVkM2M4ZWExNDM0MGQ1ZDJmN2U4OWMwMmUwZmM5MjBjNDg4YjFjZTJiOGViOWUzOWJlYWI0In0.eyJhdWQiOiIxIiwianRpIjoiNjAzMDIzNzA3ZDYzYTBiMzA0ZTIxMTA3ODVlNWQzYzhlYTE0MzQwZDVkMmY3ZTg5YzAyZTBmYzkyMGM0ODhiMWNlMmI4ZWI5ZTM5YmVhYjQiLCJpYXQiOjE1MDAxNDk2MzYsIm5iZiI6MTUwMDE0OTYzNiwiZXhwIjoxNTMxNjg1NjM2LCJzdWIiOiIiLCJzY29wZXMiOltdfQ.xDX4O2ksFGNsOKGKZldeQJH8dWWKBfHFDUsgPHP6o6nZ_tQ3TQEJ9NhPF3rk6teDAtSh2O0uu3qY9YJukYZvkKdcY8FH2cq9wDk6Fzukj1ZvsZgWSe0-gnUduHH-xPdU5-vskuJw7wvdA6vwk60lr5N-rAsOE3GfsBpIggx4OItahTUZW579rcLPEjgumRtXp9jRd5lg-96QssRgZyT5OwnhxxwLrnBMuaZfrc6plVeETQFrwWoB8ZMXiraxJkB4xbY10V7JyQIIeSuex3D3a5Ff9goI8lXAAOiu3pfj6HBt6tCsWYf3ZEAWk6CQg1tSc4o5Ts55IKOu5l0DG2Qb0rIDluCJpTSHCSZHwEejRSwxxHfY4gX6rcYEInEsmpRTV1YsGKxSaHDv_dSp4Ep1OFxET8DmeHZb5TwZM3uvkoDHS4VUgik_3PYXiWSgc7XDaJa8fr-RsYWxbNc_s3KAmyB-y-TEHZhcuemW-aBj5NTfui9iW9xTYpUFE_QzaCGaORmMTQLg9ktthFAuNy84j3huVYWDIUYGbDV3du1dA4eSHESO6uePkz4QbcHfLrNG33sPj8Re0kmlVRAIX_FoYASO4psXCHbiL6xm9Gv6JbjJ-cHOX6T8hsHP9hlCv0OgGJ36YymHWeuYeBYyWz9fb66uFcwfj8S8HJVstT51Gs8"} )

and I also want to know how I can display users records with verified access token so I can add/edit/delete/view users records.

@paypipes The response you are getting is the bearer token when you call something like oauth/token in order to authenticate against your API.

The bearer should be long, there is no problem in that.

I have also installed the package lumen-passport and I don't have any issues, please let us know the specific problems/errors you are getting, in order to try to help you.

dusterio/lumen-passport works fine for me

@dusterio I'm having trouble installing your package for Lumen 8Your requirements could not be resolved to an installable set of packages.

   - lcobucci/jwt[3.3.0, ..., 3.4.x-dev] require php ^5.6 || ^7.0 -> your php version (8.0.14) does not satisfy that requirement.
   - Root composer.json requires dusterio/lumen-passport ^0.3.4 -> satisfiable by dusterio/lumen-passport[0.3.4].
   - Root composer.json requires illuminate/notifications ^8.49 -> satisfiable by illuminate/notifications[v8.49.0, ..., 8.x-dev].
   - Root composer.json requires tymon/jwt-auth dev-develop -> satisfiable by tymon/jwt-auth[dev-develop].
   - tymon/jwt-auth dev-develop requires lcobucci/jwt <3.4 -> satisfiable by lcobucci/jwt[1.0.0, 1.0.1, 1.0.2, 1.1.0, 2.0.0, ..., 2.1.x-dev, 3.0.0, ..., 3.3.x-dev].
   - You can only install one version of a package, so only one of these can be installed: lcobucci/jwt[1.0.0, 1.0.1, 1.0.2, 1.1.0, 2.0.0, 3.1.0, ..., 3.4.x-dev, 4.0.0-alpha1, ..., 4.2.x-dev].
   - Conclusion: install lcobucci/jwt 4.0.4 (conflict analysis result)

You can also try re-running composer require with an explicit version constraint, e.g. "composer require dusterio/lumen-passport:*" to figure out if any version is installable, or "composer require dusterio/lumen-passport:^2.1" if you know which you need.```