Login with json_login

Hey Paul!

Very cool setup! Ok, I think you've done the hard parts, we just need to clarify a few things.

1) First, you should only have 1 authenticator. In this case, your custom authenticator. You only need 2 authenticators if there were legitimately creating two separate ways for your user to log in. In your custom authenticator, you are really already doing all of the "work" needed for authentication. The only missing piece, if I understand things correctly, is the JWT response. So, we're going to move that into your custom authenticator. Remove all the json_login stuff.

2) Yes, you DO need a route for /authentication_token, or whatever URL that you want your custom authenticator to "operate on". And, json_login does NOT have anything special about this: it TOO needs this URL/route and it does NOT create it automatically (it's possible the lexik bundle adds it automatically in some way, I can't remember). Anyways, this is no big deal, and to understand why, let me explain the "flow" of what happens on authentication:

A) The user POSTs to /authentication_token with whatever data
B) In Symfony, BEFORE the security system (i.e. your authenticator) is called, Symfony executes its routing. If /authentication_token does not match a route, boom! The 404 page is triggered BEFORE the security system is ever initialized.
C) Assuming a route WAS found, the security system is then initialized.
D) IF your authenticator is successful, then what happens next depends on your onAuthenticationSuccess method. If you return a Response (which is what you want to do - more on that soon), then that Response is returned and the controller attached to the route (if there is any - it's possible to create a route in YAML that has no controller) is NEVER executed. If you return null from onAuthenticationSuccess, the request continues and Symfony executes the route.

Based on your error, I think you DO have a route for /authentication_token, but it is not attached to a controller (very likely this lives in config/routes.yaml or config/routing/{some-other-file}.yaml). And that is ok! This route exists PURELY so that Symfony doesn't trigger a 404 too early in step (B).

What you need to do is implement onAuthenticationSuccess() and return a JsonResponse. Can you reuse the lexik_jwt_authentication.handler.authentication_success stuff? Actually, yes, though, it's probably easier not too - that class doesn't do all that much for you. Instead, follow the first example here - https://github.com/lexik/LexikJWTAuthenticationBundle/blob/2.x/Resources/doc/7-manual-token-creation.rst - autowire JWTTokenManagerInterface into your class, use it to generate the token, then return a JsonResponse.

The last missing piece is: how do you add your custom data to the JWT? For that, I believe you should follow this guide by adding a listener to the token creation process: https://symfony.com/bundles/LexikJWTAuthenticationBundle/current/2-data-customization.html#adding-custom-data-or-headers-to-the-jwt

Overall, what I would do is:

1) In my authenticator, get back the data you need from Cognito. Determine the "extra stuff" that you need to include in your JWT. Store this as request attributes, which are just a convenient way to pass data around during a request - e.g. $request->attributes->set('some_cognito_value', 'the-value')
2) In your event listener/subscriber (the docs show a listener, but I would use a subscriber, they're simpler as they don't require any YAML config), read these request attributes and use them to modify the data/payload on the JWT.

And... let me know how this all goes!

Cheers!

Hi Ryan,

I was evidently frustratingly close - just removing the json_login yaml block and implementing the JsonResponse on success got me over the line (I'd already implemented a failure response). I used what I think is an EventListener for onJWTCreated rather than a subscriber, since that's what the documentation suggested and I'd already partially implemented it.

So now I can use the API /authentication_token endpoint to log in against Cognito and return a JWT with the Cognito access and refresh JWTs embedded inside, along with some other specific user-related parameter from the API database. And when I call another endpoint with the BEARER token, I can access those parameters. [EDIT: I suspect embedding the Cognito tokens inside the API platform access token isn't the right option - I'll likely change it to return the tokens separately - but that a simple refactor now that it's working.]

I'll need to work out token refreshing and password update / reset via the API, but that's less urgent for the current stage of my project.

Thank you very much for getting me unstuck again!

Kind regards, Paul

Hey Paul!

Awesome job! Thanks for sharing your success - I think this is precisely the slightly-more-advanced use-case that the lexik bundle wants to make possible. So very cool to see that you've done it!

Keep up the good work :).

Hey Leonel D.!

Woo! I'm glad it's useful!

> I I tried to do the same with React but without success, isn't there an authentification tutorial with React?

Because we're using cookie-based session authentication in this tutorial, it shouldn't require *anything* special in React. Quite literally, the steps are to:

A) Create a form
B) When that form submits, send a POST Ajax request to /login, including "email" and "password" POST parameters (not as JSON, just as normal POST fields on the request).

And... that's it. You don't even need to do anything with the response. If that Ajax call is successful, its response will contain the session cookie, which your browser will automatically start using. The reason it is a POST request to /login with email & password as POST parameters (not JSON) is simple because that's how I build the "form login endpoint" for this project. We're also using Axios for this in assets/js/components/LoginForm.vue, so you should be able to copy and paste that into your "on submit" React function and have it work just the same.

Let me know if that helps :).

Cheers!

Hey Jean-tilapin!

Hmm. So when you SEND data (like a PUT or a POST), the serialize will use the "deserializationContext" groups, which you might have configured directly on your ApiResource annotation/attribute or you might have configured specifically for that operation. But when that endpoint serializes the data to return to the user, it will then use the "serializationContext" groups... so you should get the same behavior as when you GET a specific user. So I would check and make sure your serializationContext config for the PUT endpoint are what you expect. I usually set this on the "ApiResource" level so that it applies automatically to all operations. If you have *not* configured it at the "ApiResource" level (i.e. directly under the annotation/attribute) and are instead configuring this on an operation-by-operation basis, then you need to make sure that it's also configured for your PUT operation. Overall, it definitely sounds like, for some reason, when it "serializes" for your PUT operation, it is serialization with NO serialization groups (and thus it is included all fields).

Let me know what you find out :).

Cheers!

Hey Jeremy Pasco!

Nice to chat with you :). And good questions!

I discovered that the config framework.yaml file had no more session configuration by default.

Hmm. I believe that there IS still cookie config in the default framework.yaml file: https://github.com/symfony/recipes/blob/0aadfa1169876356288225f3d6028cf07cdde48a/symfony/framework-bundle/5.3/config/packages/framework.yaml#L9-L13

My guess is that you may have started your project with the API Platform distribution? If so, then yes, the cookie config is not there by default :) https://github.com/api-platform/api-platform/blob/main/api/config/packages/framework.yaml

and to put the stateless attribute to false in api_platform.yaml

I think you mean security.yaml (but please tell me if I'm wrong). And yes, you would need to set stateless: false to get session based authentication to work (or remove stateless entirely, as it defaults to false. security.yaml does not have a stateless key at all when you start).

But... I'm wondering what are the consequences of disabling the stateless mode. For example, will it impact the Varnish cache? Will I get each results cached for each user (because of auth data included in reaquests)?

You've probably nailed the only (but potentially big) downside. Varnish does not like cookies :). But let me back up and say that I'm far from a Varnish expert. But I believe that, by default, if a session cookie is sent on a request, then Varnish does not cache that request... or it at least "varies" by that cache value, I can't remember exactly. You certainly can write some vcl to tell Varnish to not do this: to treat /api/products the same regardless of the session cookie, which is what I would do. Of course, you then need to be very careful not to "cheat" and start returning different results from /api/products based on the current user :).

Let me know if that helps a bit!

Cheers!

Thanks for your reply, it helps a lot!

> My guess is that you may have started your project with the API Platform distribution?

I am indeed using the distribution instead of bundle installation.

> I think you mean security.yaml

The stateless attribute I changed was in api_platform.yaml ( https://github.com/api-platform/api-platform/blob/main/api/config/packages/api_platform.yaml ) but you're right, security.yaml allows it too. I guess that the api_platform one is just a way to inject the stateless attribute into the api_platform security config?

> You certainly *can* write some vcl to tell Varnish to not do this

Thanks, it confirms my intuition. The more I work with API Platform, the more I feel that I won't be able to elude VCL much longer :)
At first, I considered going back stateless (with JWT) just to avoid this. But I end up having few other endpoints with custom operations that cannot be fully cached (like /me or other computed entities not related to auth). Sometimes, these endpoints return strange result sets depending on which user asked for it previously. At the end, I feel that handling Varnish properly is not an option.

Hey Jeremy Pasco!

> The stateless attribute I changed was in api_platform.yaml

Ah! I actually didn't know about this option! It looks like it comes from v2.6. This causes the routes defined by your API to be "stateless", which *prohibits* the session from being used - https://github.com/symfony/... - that's a cool feature :).

Anyways, you would, indeed, need to remove stateless in both spots, but they are 2 different things:

A) API Platform "stateless" config - prevents session usage on API Platform routes
B) security.yaml "stateless" - tells the security system not to store (or read) a session cookie that contains authentication information.

> Thanks, it confirms my intuition. The more I work with API Platform, the more I feel that I won't be able to elude VCL much longer :)

Oh caching :). I don't know your situation, but in general, I look for the "low hanging fruit" and cache that stuff :). So, cache endpoints that are heavy, frequently used AND that you know won't contain user-specific data. Then, don't cache the rest. But, it could be that your heaviest endpoints are the ones you need to cache most... so it really depends on your situation :p

Good luck!

Hey @Jesse!

Hmm. First, it sounds like you are checking the correct places: you've checked that the response header DOES contain a Set-Cookie header... and you've verified that the cookie is NOT being stored. The only reason I can think of that this would happen is that your browser is rejecting the cookie. The most common reason this might happen is if your frontend and backend are on different domains - do you have a situation like this?

Cheers!

Thanks for the reply! Yes that is correct, we have the backend running on a separate server then the frontend. From reading up a bit more, would the solution be, using SameSite cookie as none and running the server through https? Or is there a better alternative? Had no luck so far trying to get a self signed certificate and vue js setup properly in Windows 10.

Hey @Jesse!

Sorry for the slow reply - I had a family matter come up.

Ah, yea, life gets more complicated when your frontend and backend aren't on the same "host". If they are under the same domain... but just have different subdomains (e.g. frontend.example.com and api.example.com) then that is ok: you can configure your cookies to use the domain example.com and everything will work fine (even with SameSite cookies). But, my guess is that you are not so lucky and you have 2 legitimately different domains. In that case, I believe that session-based authentication (i.e. with cookies) may not be an option for you - and tbh, this isn't an area that I have a lot of practice expertise. But generally speaking, I think you might need to rely on normal API token authentication instead of cookies... or find some workaround - e.g. https://stackoverflow.com/q...

> would the solution be, using SameSite cookie as none and running the server through https

Umm... this might work too :). I suppose you could have your backend set the cookie on its domain... with SameSite set to none.. then it should be sent back on future requests to the backend. Of course, you'd need to consider the security ramifications - specifically protected from CSRF attacks on your API.

Sorry I can't be more clear - my head is still a bit jumbled from being away for a week and this isn't an area that I have had to tackle in the real world.

Cheers!

Hi, i'm using the same configuration as you said api.exemple.com and frontend.exemple.com in the same domain but how
i can configure my cookies to use the main domain : exemple.com ?

Cheers !

Hey Youenn T.

Have you tried this config?

framework:
  session:
    cookie_domain: .example.org

Cheers!

Now I'm with this config but when I using my /me on production

i got this in my request :
`
PHPSESSID

domain    ".exmple.com"
expires    "1970-01-01T00:00:01.000Z"
httpOnly    true
path    "/"
samesite    "Lax"
secure    true
value    "deleted"
    
PHPSESSID    "mo3lub68kgpfjcqi6sior8stje"

`

Everything works fine in localhost with the same domain

I'm not sure I follow you but on production, you have to use set your production domain.

Hi Jean-tilapin!

Nice to chat with you again!

For authentication, I use Lexik JWT Bundle with the Http Only Cookie Mode. So far I've managed to make all that working together : API calls, authorization through the cookie, that's great. A lot of work to do, still.

Awesome work! I am personally a fan of, good, old-fashioned cookie/session authentication, but what you need varies case-by-case :).

Only One thing is missing : the user profile! I want my user to click on a "my profile" button and get its infos, so I'm guessing I need to make a get call to "api/users/{id}", where the id is the current user id. But how am I supposed to get its own id

Personally, I would render (in Twig, in your base layout) a global window.currentUserId = {{ app.user.id }} global variable. Or I might even set a global variable to some actual user information to avoid the need for an AJAX request to get that basic info. I guess you could also store some user info in local storage, but it makes sense to me to communicate some information from the server to the client-side by outputting some global vars (you could also, for example, add something like a data-user="" attribute on the body tag - that's kind of a matter of preference versus global vars.

So... let me know what you think about this and if it works for your situation. It's such a simple solution, that I'd like you to tell me if it doesn't work (and why) before I suggest alternatives :).

Cheers!

For now, I've solved that issue with this technique (I don't use Twig, only Vue with vuex, vue-router and vuetify): https://github.com/api-plat...
It's quite simple but I still have a lot of trouble understanding what is - or not - a "best practice" with Api Platform.

FOSRestBundle seems to be more friendly, but too late, I've made a choice, I have to stick with it.

Now I have a new issue (great!) : configuring the security.yaml to allow users from Lexik JWT authenticator AND users from the admin back-office with traditional login form to both access the API, with different privileges. If you have some time to waste...

Hey @Xav!

Nice job solving the issue!

> It's quite simple but I still have a lot of trouble understanding what is - or not - a "best practice" with Api Platform.

API Platform talks a lot about REST best practices. And so often, there are perfectly fine solutions that are not RESTful, and so it seems (when reading the docs or issues) that this is "not a good solution". It is, it's fine - good job ;).

> Now I have a new issue (great!) : configuring the security.yaml to allow users from Lexik JWT authenticator AND users from the admin back-office with traditional login form to both access the API, with different privileges. If you have some time to waste...

My first question would be: do you have aa single "User" object in your app or 2 User objects (one for the normal JWT authenticated users and another for the admin users)? Hopefully you have one (not that 2 is wrong, it's just more complex). If you *do* have 1, then it's all comes down to:

A) On login, intelligently setting roles based on the JWT or the admin. So, ultimately the authentication is different, but you use different information to decide the roles the user should have.

B) If that is too simple (or for cases that are not this simple), rely heavily on voters - you can do anything in them. Heck, you even have access to the authentication token so you could know in a voter if a user authenticated via JWT or normal login.

Cheers!

Anton K. - You're selling us a bit short. We have this working in production on multiple sites. Also have it working between different domains and Ionic smartphone clients. How far along are you? Any specific errors? Be sure you're using "withCredentials: true" client-side and you're using some type of CORS Bundle on the Symfony4 side. Cheers!

Hi Anton K.!

Fortunately, you're not the first person to ask this :D. The short answer is that remember_me does not work with json_login. But if you re-implement json_login as a Guard authenticator (which is not too difficult), you *can* make it support that. Check out the thread for answers here - https://symfonycasts.com/sc... - and let me know if you have some luck.

Cheers!

Hi @skywaler!

That's a really excellent question - and not something I've had to implement before! So, if your backend is hosted on another server, are you still using session-based authentication - i.e. the other server sets a cookie and your JavaScript sends it to be authenticated? If so, indeed - that complicates things :). First, let me say that this stuff is *tricky*, so I'll do my best to be accurate here - but I can't make any promises.

Because of your setup, the session cookie that's set by the other server doesn't use SameSite... which means that it *is* in theory vulnerable to CSRF attacks. From some looking around, it looks like you could implement CSRF by using headers or by using cookies that only your Angular domain can use - https://security.stackexcha...

The topic in general doesn't really relate to API Platform - it's more of a Symfony security setup. This bundle - https://github.com/dunglas/... - which doesn't work for Symfony 5 (as the author is mostly hoping that SameSite cookies will eliminate the need for CSRF in the long-run), is a good example of how this might all work.

A more abstract answer to your question is this: using session/cookie based authentication is GREAT when your frontend and backend live on the same domain. By using SameSite cookies, you *may* not need to worry about CSRF (most of your users will be using browsers that support SameSite). If you have your frontend and backend on different domains, security is just tricky. You probably don't want to use session-based authentication (using token-based instead), but now you have the problem of storing authentication tokens in JavaScript, which can be dangerous. And this leads to another solution: put a backend on the same domain as your frontend... which makes the API requests for you. This is actually what GitHub does. The JavaScript on GitHub.com does *not* talk to the GitHub API directly, as far as I've seen. Nope, it makes AJAX requests back to GitHub.com and uses session-based authentication. Behind the scenes. the GitHub.com backend probably makes API requests to the GitHub API using API tokens.

I hope this helps - but sorry if it does not ;). I could be wrong about some of these details - but I've spent a lot of time researching them.

Cheers!

Hey Simon D.

I'm not sure how you are doing your API calls but seems to me that you are not sending the session cookie. We explain how in this chapter https://symfonycasts.com/sc...

Cheers!

Actually, I think my problem is that I have separated the front and back-end (as per API-Platform recommendations) so that they're currently on different ports of localhost - my thinking being that in production I can have them on different servers or even different domains.
However, according to https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch:
fetch() won't receive cross-site cookies; you can’t establish a cross site session using fetch. Set-Cookie headers from other sites are silently ignored.

So I have a new question for you and Ryan: Do you still consider session cookies to be an acceptable means of authentication for APIs when the front and back ends are separated like this?

The folks at API-Platform seem pretty adamant that JWT is the only way to go for APIs.

Ohh, I see your problem. I found this article that explains how you can send your credentials via CORS request http://promincproductions.c...
I'm not sure about how secure it is, it's possible that's not the most secure option but it should work. If you don't like it, or you are aware of any vulnerabilities, then, using JWT would be your option

Cheers!

Thanks,
In the end, I compromised by going back to JWT but setting the token in an http-only cookie.
This gives me greater flexibility for the future, seems more secure and has the advantage of being a genuinely RESTful solution.

Hey Taieb!

As far as I understand it, absolutely :). The JWT that you configure with MecureBundle will be used to communicate and authenticate against your Mecure hub, not your Symfony app. Basically, when you set up the Mercure Hub, you configure some secret key (not a JWT) on the JWT_KEY setting. You then use that key to create JWT's that will be used by MecureBundle / your app. Basically, you'll create a JWT that has this structure (https://jwt.io/#debugger-io?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJtZXJjdXJlIjp7InN1YnNjcmliZSI6WyJmb28iLCJiYXIiXSwicHVibGlzaCI6WyJmb28iXX19.afLx2f2ut3YgNVFStCx95Zm_UND1mZJ69OenXaDuZL8) and then sign it with the same "key" that the Mecure hub is using (see https://github.com/dunglas/mercure/blob/master/docs/getting-started.md#publishing and https://symfony.com/doc/current/mercure.html#configuration)

I hope that helps. The key this is that your Symfony security and this whole "JWT Mecure" thing have nothing to do with each other :). The Mercure thing is all about communicating securely between your Symfony app and the Mercure hub.

Cheers!

Hey Egor,

Thanks for this tip! I see Canary is unstable yet, so probably this issue might be related to this.

Cheers!

Hey Sung L.!

Sorry for the slow reply! Let's get to these questions :)

First, it seems like you can still see /api page and run commands in the page without any authentication. How can I make /api page require login?

If you'd like to do this, use access_control in security.yaml to require, for example, ROLE_USER or ROLE_ADMIN. Basically, you can use normal Symfony security to protect this if you'd like.

Second, do you have plan to add JWT authentication in API Platform in this tutorial?

No :). In a future tutorial, we're going to talk about some different authentication schemes beyond the one we show here. That's on purpose - I think JWT is being over-used - its truly useful if you have a central authentication system and then many different applications where you want an API client to be able to talk to all of these with the same "token" and avoid all of these separate apps from needing to communicate back to the central authentication system on every request. It's a situation that few people actually have. For many use-cases, you should be using HttpOnly cookie-based authentication... which could be a session cookie or JWT. Though, while this is a fine use of JWT, it doesn't really offer any advantages over session-based auth in most situations and is more complex to setup.

That's why we won't talk about it in this tutorial... but I do want to expand on all of this in a future tutorial. Let me know if that helps :).

Cheers!

Hey Sasa,

All popular JS frameworks have both pros and cons, and most of the time the choice between of them falls on one that you know the best :) Really, if know a JS framework and you're comfortable with it - just use it. Well, sometimes it's more complex choice because your choice may depends on your project and its needs. But what about working with API - I think all popular JS frameworks are good in it, that's a pretty simple thing and it's more matter of taste.

Well, if you're interested about our opinion - we love ReactJS, and we have a screencast about it: https://symfonycasts.com/sc... . Also, we're looking at VueJS, so probably the further screencasts might be based on it, but it's not 100% yet :)

I hope this helps!

Cheers!