API Auth 101: Session? Cookies? Tokens?

Hey Nick!

Apologies for the slow reply - holidays!

I was thinking of a simple api key authorization system. Is this session/user login based authentication system applicable to me?

The session/user login might be applicable for (1) depending on "who" is making these requests. But for the other items, no, it's not relevant. If you truly have just a single email provider and a single phone provider that need to make requests, you could build a super simple api key system. Heck, you could even hardcode those 1 or 2 tokens into your config - no need to complicate things.

If not, which part of this api security course would be most relevant?

You'll need to build an authenticator for the API token system. But other than that, pretty much the rest of this tutorial is relevant because it is not about authentication, but more about applying authorization rules (i.e. denying access) or returning data based on the user. Well, this will be relevant to you if you have these use-cases. Let me know if you have any questions about the api token authenticator that you'll need to build.

Cheers!

Hey Pedro S. !

Apologies for the slow reply!

Is there a way to generate two different session cookies (one per each frontend) to be able to achieve that scenario?

Hmm. Yes, I believe what you need to do is change the session cookie name used by each app. By default it is PHPSESSID, but that can be changed. I believe this can be set in framework.yaml via:

framework:
    session:
        name: OTHER_NAME

Let me know if that helps.

Cheers!

Hey Sridhar,

This is the 2nd tutorial, we created that User entity in the 1st one, exactly here: https://symfonycasts.com/sc... . We based the code of this tutorial on the finish code of the first tutorial, so it's like continuation of the 1st tutorial :)

If you skipped the first tutorial and started from this one - you would need to create User yourself, or we always recommend to code along with us downloading the course code and start from start/ directory - it will contain everything you need to start this course :)

Cheers!

Hey Krzysztof K.!

I can definitely help with this :). The answer is to listen to the "jwt_created" event - I talk a bit about it here: https://symfonycasts.com/screencast/symfony-rest4/jwt-guard-authenticator#comment-4497986969

The docs you linked to - https://github.com/lexik/LexikJWTAuthenticationBundle/blob/master/Resources/doc/2-data-customization.md#eventsjwt_created---adding-custom-data-or-headers-to-the-jwt - I think is up to date. Well, sort of :). The docs are written on a way that would work - but there are easier ways to do things now. Here's what I would do:

1) Run bin/console make:subscriber
2) When it asks for the event name, type in lexik_jwt_authentication.on_jwt_created

That will generate the subscriber class for you - not YAML configuration will be needed. Then you can make the method in the subscriber class look like the example in their docs look: https://github.com/lexik/LexikJWTAuthenticationBundle/blob/master/Resources/doc/2-data-customization.md#example-add-client-ip-to-the-encoded-payload

Let me know if you hit any issues :).

Cheers!

Hey Joel L.!

Sorry for the slow reply :). I've never had to implement this specifically - so I can't say for sure from a perfectly-educated place :). In theory, you could still use session-based cookie authentication as long as you whitelist your frontend's domain in CORS. However, I "think" that this will simply *not* work with a samesite cookie, which you *do* want to use.

So in this case, you probably would need to use some sort of API token to make authenticated requests to the API. I just don't love this because it means that, on some level, you're going to be needing to "keep track of" something sensitive - like an API token - in JavaScript. If you're careful and just keep it on a scoped JavaScript variable, I think you're ok (but "I think" is not a strong statement in security). However, even if that's true, unless you truly *store* it somewhere (like local storage or a cookie that JavaScript can read) then when you refresh, it will be gone and the user won't be authenticated. But as soon as you "store" something sensitive in JavaScript, you're asking for trouble. Basically, I think you're on shaky ground here, and it's why having some backend that's on the same domain as you is super handy... even if that backend itself is just making requests to some other API (but then it can securely store the authentication info, instead of JavaScript).

I hope this helps! Tough stuff :/