Not enough integration with Passport about sanctum HOT 7 CLOSED

If you're already using Passport (and you need oauth) then continue using Passport... you don't NEED Airlock for stateful authentication, as Passport can provide it for you. See https://laravel.com/docs/5.8/passport#consuming-your-api-with-javascript

On the other hand, if you don't need oauth... then get rid of passport and use airlock instead.

If you're keen on keeping both (or need to), HasApiTokens could differ between Passport and Airlock (if it doesn't already, I haven't checked) so I'd use the one you plan on implementing instead of assuming they're the same.

To answer the second half of your question, you don't need any special or custom login methods to return tokens for a first party frontend. Assuming you're using a default laravel auth scheme, you simply use AuthenticatesUsers in your AuthController and then from your SPA login page:

1. GET /airlock/csrf-cookie, then (if you receive a 204 response):
2. POST /login with { email: '[email protected]', password: 'abc123' }

If you get a 200 OK from /login, then you're authenticated (which means the cookie has been created and there's a valid session associated with it) and subsequent requests will succeed.

from sanctum.

Also, is it possible to use airlock with things like telescope?

from sanctum.

Please see the answers by @bcorcoran

from sanctum.

@bcorcoran okay, that makes sense I suppose, but how do I go about getting the CSRF cookie from passport as it's only recommended to inject it when serving the front-end, however, my front-end is served by another server entirely.

Also if that's the case, why does airlock even support or mention passport at all? shouldn't it be a "use airlock OR passport, not both"

from sanctum.

@KieronWiltshire you don't in that scenario. Passport isn't designed in that way. Airlock, however, is... hence the /airlock/csrf-cookie route.

If you want to use Passport for something like this, you need to deal with storing the token on the client and keep passing it back to the server for every request.

With Airlock, you're authenticating & receiving a cookie and as long as you have the domain in the airlock whitelist, it will be valid.

from sanctum.

@bcorcoran so I guess I need to use both then?

from sanctum.

@KieronWiltshire I don't know- I don't know the requirements of your application and this really isn't the place for this kind of support. That being said, if you need oauth... then keep Passport. If you don't, get rid of Passport and use Airlock.

If you're asking if you need Passport and Airlock together to authenticate a frontend on another server... no, you only need Airlock.

from sanctum.