JSON Web Tokens (are awesome)

Hey @AbelardoLG!

Excellent question(s)!

> So, does the client need to send it each time it makes a get, put, post, etc. request or it only serves to auth processes

Yes. If you're using a token authentication solution, then in JavaScript, on every API call, you would include it.

> If so, the client has to store this data: via cookie or by security reasons is better it is not stored??

This is one big complication or downside of trying to manage tokens in JavaScript (vs using cookie-based session authentication... but session-based cookie authentication is NOT an option if your frontend JS and backend API live on different domains). I'm not an expert on this, and I know that it needs to be done thoughtfully. I'd check out Auth0 on this: they are a pro source for info: https://auth0.com/docs/secu...

My preference, in general, is to avoid messing with API tokens in JavaScript and instead use cookie-based session authentication. However, this requires that you have a backend that lives on the same domain as your frontend. But, that's *really* the easiest path. Even big sites like GitHub - who have a fully-featured API - do not actually use their API from their frontend. If you look carefully, GitHub's JavaScript doesn't make Ajax calls to their API: they make Ajax calls to github.com itself... which then returns data (behind the scenes GitHub.com itself might/could make API requests back to api.github.com if it wanted to... and it would be able to do that safely, as it could store any access tokens in the backend).

I hope this helps a bit :).

Cheers!

Btw, I am going to navigate through your website by looking for a course about how to handle session cookies with Symfony.
Thanks for your nice website! :)

Hey Abelardo,

We glad to hear our website is useful for you! Make sure to check out advanced search on the website, it searches in video, comments and even in code blocks we have below videos! It should help a lot with finding information :)

Cheers!

Then no problem in my case!: inside my twig templates my JS scripts live. Here I could add my Ajax calls to my Symfony API.
But...then my jwt token would be visible.mmmm....🤔 A big problem, right? My JWT Token could be used by using bad techniques to hack my website. 🤔

Imagine this scenery:
" < a href = "{{ path('aRoute', { myJWTToken: jwtToken } ) }}"> Edit this user < / a > "
At this place, my jwtToken would be visible by inspecting the source code.

Am I right or again I am wrong to understand how to use the jwtToken inside my Twig templates (no JS here!)?

Thanks and best regards, Ryan!

Hey Abelardo L.!

Yea, this gets tricky. So first, don't use JWT (or any API tokens in your JavaScript) if you can avoid it. By "cookie-based session", I am referring to (A) creating a normal log in form and (B) POSTing to that login form via Ajax. That's it :). The login form AJAX post response will return a session cookie... and all future Ajax calls will pass that cookie and be authenticated.

If you ARE using API tokens in JavaScript, I'm not an expert here. But certainly, your example of embedding it into HTML would be a problem. I think the idea is generally to store the token in ONE place and for that to be "in memory" (e.g. not somewhere like local storage) and NOT global. So even doing window.API_TOKEN = '' makes it possible for some 3rd party JS on your site to read that. In other words, it's tricky. I look to Auth0 here for best practices on how to store the tokens.

But, more generally, this example looks a bit odd to me:

<a href = "{{ path('aRoute', { myJWTToken: jwtToken } ) }}"> Edit this user </a>

This tells me that you have a Symfony backend that is rendering HTML. In that case, there's no reason to use API tokens. I'd log into "my backend" use a normal login form (you can submit it via Ajax if you want it to look fancier). If this jwtToken is... actually so that you can reference some OTHER API (i.e. you have (i) a frontend, (ii) a Symfony backend and (iii) a separate API that you talk to), then you should store the jwtToken on the backend somewhere (e.g. even in the session) and then use that in your Symfony code to make API calls.

Let me know if this is helping to clarify... or not :).

Cheers!

Hey ponder!

Sorry for the slow reply - SymfonyCon was last week and kept us busy! First, what's your motivation for using the JWT for authentication and then a separate access_token after? I'm just making sure I understand what you're trying to do. And second, there is probably not a bundle for what you're thinking of - there is of course LexikJWTAuthenticationBundle for using JWT in general, but for a more specific implementation, you'll probably need to add it yourself. So, you are not missing anything!

Cheers!

Hey Lijana Z. !

Really good question. The WHOLE point of "API tokens" is this: to have some "string" that allows access that is different than the user's password. Let me say it a different way. Yes, if you're using SSL, there is no security risk to sending your email/password, credit card information, API token or anything else to the server. So then, why do we have API tokens at all? Why not just have the user *always* send their email/password to the API endpoints?

Actually, this *is* a valid way to do it. And, like we just talked about, over https, this doesn't really have any security implications.
The *real* reason for API tokens is that you can create an API token and safely give it to someone else. Then, if you decide that this "other person/app" should not have access to your account anymore, you could (in theory, it depends on how you build your system) invalidate/delete that API token. Heck, you could give out 10 different API tokens to 10 different users. And if you want to deny access to just one of them, you only need to invalidate/delete that API token for 1 app. The other 9 will work, as will your password. Additionally, in a more complex system, you can make some tokens have different permissions than others.

So, if api tokens did not exist, we would be forced to give other apps our password. And then, if we changed our password (because we wanted to deny access to 1 app that we shared it with), we would invalidate access for all of those apps. This is how, for example, OAuth works with Facebook. If you clicked "Login with Facebook" on SymfonyCasts, you are basically creating & giving SymfonyCasts an API token that gives some access to your Facebook account. SymfonyCasts then sends that token on API requests to Facebook to perform certain actions "as you" (well, we don't do that - we just fetch your email for login purposes, but you get the idea). If you wanted to "invalidate" our access, you could go to Facebook and "revoke our access", which basically makes our API token invalid.

Phew! The big question with all this API token stuff is: how do you want your users to be able to create API tokens? In this simple app, we created an API endpoint where you can create them. Then, in theory, you could safely give those to someone else. We could also implement an OAuth server (then we would operate a big like Facebook) OR we could create a simple profile section where each user can manually create access tokens (you can do this on GitHub). We actually have an entire short video on this exact topic: https://symfonycasts.com/sc...

Let me know if that helps!

Cheers!

Thats a long answer. I think I did not understand most of the things, I need to reread it slower but currently have other stuff to watch. I mark it to come back later. But one thing instatly raises question to me:

"So, if api tokens did not exist, we would be forced to give other apps our password. And then, if we changed our password (because we wanted to deny access to 1 app that we shared it with), we would invalidate access for all of those apps."

You mean 1 password for every user? I think every user would have their own pasword and so we just deny access to one user. But since I did not take time to think much, that might be a reason why I did not understand.

Hey Lijana Z.!

> So, if api tokens did not exist, we would be forced to give other apps our password. And then, if we changed our password (because we wanted to deny access to 1 app that we shared it with), we would invalidate access for all of those apps.

Ah yes, I DO mean that every user would have their own password. Think about Facebook as a good example: imagine I have an account on Facebook (and I of course have my own, unique password). Now, I want to allow some other site - e.g. SymfonyCasts - to access some information on my Facebook account via their API. If API tokens did not exist, then I would need to give SymfonyCasts my Facebook password... so that SymfonyCasts could use it in API calls to Facebook. Sure, there might be the same fancy OAuth flow to "pass" my password to SymfonyCasts. But, the important thing is that, ultimately, SymfonyCasts would have my password. Now, imagine I also want to allow some other site - e.g. GitHub - to be able to access my Facebook account via the API. Now I would *also* need to give GitHub my Facebook password.

This situations has 2 major issues:
1) Because SymfonyCasts and GitHub have my password, they can actually do ANYTHING with my Facebook account, including post things to my wall. One of the advantages of API tokens is that (if you need to) you can make an API token only have *some* permissions for an account, instead of ALL permissions.
2) Imagine that we no longer trust GitHub and we want to "revoke" access - we don't want GitHub to be able to access our Facebook account anymore. The only way to do that is to change my password on Facebook. But, when I do that, I've also (accidentally) revoked access to SymfonyCasts.

I hope that makes sense! The argument for API tokens is pretty clear. But also, you don't *really* need them unless you want 3rd parties to access your API. If you're building an API ONLY so that your OWN JavaScript can access it, using session cookies is a simpler approach.

Cheers!

Hey einue!

Ah, very interesting question :). I'll explain a bit using the new (version 2) of the https://github.com/lexik/Le..... though the details will essentially be the same for version 1.4.

The most important thing to know is that the bundle relies on a *different* library to actually do the key stuff. It either uses https://github.com/namshi/jose or https://github.com/lcobucci... based on your configuration. So let's talk about the first. If you look at their docs, they explain it fairly well: https://github.com/namshi/j.... Basically, the private key is used to sign the key, and then the public key is used to verify it.

This *is* different than asymmetric key encryption. But... it's kind of the same idea in a different direction. I may be off on some finer details (security is always tricky), but basically, if you have a public and private key, you can use it in 2 different ways:

A) Encryption: Encrypt data with a public key, and decrypt with a private key (like how SSL works)
B) Signing: Sign data with a private key and "verify" its authenticity with a public key (JWT)

I hope that helps!

Cheers!

Just making sure you're aware ;). Thanks for pointing that out - we'll get that fixed and re-export.

Cheers!