Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not enough integration with Passport #52

Closed
KieronWiltshire opened this issue Jan 21, 2020 · 7 comments
Closed

Not enough integration with Passport #52

KieronWiltshire opened this issue Jan 21, 2020 · 7 comments

Comments

@KieronWiltshire
Copy link

So I'm actually using passport to authenticate my entire API. However, I've now reached the point where I actually need stateful authentication for a first-party front-end.

I found airlock as a possible solution, but I don't understand how I'm supposed to use airlock and passport together, and I think this is down to airlock being in development and has unfinished or unclear documentation. (or quite possibly, I'm being dumb)

So using passport, my User model already uses the passport's equivalent to HasApiTokens trait. So I'm assuming I just ignore adding the airlock equivalent - but I'm unsure, I think this could do with some clarification.

Finally, in my AuthController I have a login method which already creates a personal access token and returns it in a JSON response back to the user, now I'm assuming I'm supposed to include the Auth facade upon successful authentication and use the login method to create the session. So my questions around this premise are :-

  • Does Laravel automatically know which driver to use?
  • Does it know to use the airlock driver when creating my session instead of the passport driver, if so can this be explained how? (not required but appreciated!)
  • How are the CSRF tokens validated? I see I create a GET request, but this doesn't return anything, am I expected to pass the token through or is this automatically set for me? does this mean I need to add the CSRF protection to my API routes? if so, what does this mean for my routes that are stateless?

Clarification would be helpful! thank you.

@KieronWiltshire
Copy link
Author

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

@bcorcoran
Copy link

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: 'user@example.com', 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.

@driesvints
Copy link
Member

Please see the answers by @bcorcoran

@KieronWiltshire
Copy link
Author

KieronWiltshire commented Jan 21, 2020

@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"

@bcorcoran
Copy link

bcorcoran commented Jan 21, 2020

@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.

@KieronWiltshire
Copy link
Author

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

@bcorcoran
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants