Token Types & The ApiToken Entity

Hey @MatthiasN!

I think this is really good advice. My intention was to show people that "you can just store tokens in the database". And while that's true (just like how you can "store passwords in a database"), in both cases it shouldn't mean storing in plaintext. So yes, this is definitely a better idea.

Anyway, thank you for posting this - good advice! I'll also add a note to the tutorial about it.

Oh, and let me add some more technical details here to help people, building on what you said:

It would be better to generate an access token consisting of two parts:

• An identifier (either a random string to identify the user or maybe simply the token ID)
• A random string (secret) that is hashed using the password hasher.

So, for example, you'd generate 2 random strings, separated by a .. This full string would be the API key that you show to the user.
But then, you store the first part (the "locator" or "identifier") in the database on a locator key of ApiToken. Then you store the second part (the secret) on another property of ApiToken - but HASH it first. For example, here is how we generate the random locator and hash the secret in the ResetPasswordBundle - https://github.com/SymfonyCasts/reset-password-bundle/blob/main/src/Generator/ResetPasswordTokenGenerator.php#L52-L65

Then, when verify if a token is valid, you split the token on . to get the first and second part. You then query for the ApiToken via the first part (the locator). If found, you has the 2nd part that was just sent you to you and see if it equals the hashed secret on the ApiToken you just found using hash_equals - e.g. https://github.com/SymfonyCasts/reset-password-bundle/blob/3e0bb051a514459a3c63a5064be40208e4f34783/src/ResetPasswordHelper.php#L126

If anyone has any questions, let me know :)

Cheers!

Hey @Marko!

Sure, I think you could definitely do this :). The easy part is creating the 2 tokens. You can make a JWT after the user authenticates successfully. And you could, for example, add an apiToken property to some Company entity and allow an admin for a Company to see this in some area on your site (where they could then copy and paste this for their CRON jobs).

The trickier part is consuming the tokens, well, maybe not SO tricky I hope :). You could have one authenticator that handles the JWT. This is your normal situation. Then, you could create a 2nd custom authenticator that handles your company token. If these tokens are sent in different ways (e.g. Authorization header for JWT vs some other header for company token), that'll make your job a little easier because each authenticator can figure out "is this a token I should authenticate or is it the other type?". But you could also accomplish this by giving each token some prefix - e.g. company_ - and using that.

Anyway, I think the truly tricky part is this: when using a JWT, you are authenticating as a User. So, a User object is what you would return from your authenticator... and then anywhere in your code where you say $this->getUser(), it would be a User object. But for the company token, your authenticator would return a Company, and when you use $this->getUser() in your code, that will return a Company object. It's THAT difference that could cause some confusion in your code.

I can see two general ideas for solving this:

1) If the company token is only meant to be used for a few specific endpoints, then I might put those few endpoints under their own Symfony firewall. Then, in those endpoints, just be sure that if you're ever referencing the currently authenticated "user", that you know it's the Company.

2) Code carefully :). If you need to be able to support both a User or a Company across your entire application, then be sure to create smart security rules that do no depend on the specific User / Company object. I can give more tips about this if you are going this route and have some questions about how to do some specific things.

Let me know if this helps!

Cheers!

Hello! Thanks a lot for your answer. One more question : do you confirm that Company should implement User Interface, as a authenticated 'user'? Or not. Thanks again!

Yes it should!

Hey @MildDisaster ,

That's how GitHub access tokens, you can create many tokens on GitHub for your account. First of all, you can create different tokens with different scopes, like some tokens may have access to the private repos while others - only public ones. That's the most common and flexible structure I think :) Moreover, you can use one token e.g. for Composer and another token for your website that sends API requests to GitHub. And it's convenient this way, as you can e.g. remove that second token but the first one will still work.

But of course it depends on your personal use case, and if you're happy with OneToOne relation - go for it, there's nothing wrong with it, just some limitations I mentioned above :)

Cheers!

I think I understand. So the relationship is more (but not exclusively) between tokens and apps ( that a user will use to access api with ) ?

What is the preferred way to handle tokens once an associated account is changed, ie (password recovered) ?

Should one invalidate existing tokens, or just let them be ?

I noticed in the symfonycasts github there are projects for account registration and password recovery. Without double checking, don't think there was mention of token cleanup in them.

Thanks !

Hey @MildDisaster ,

I think I understand. So the relationship is more (but not exclusively) between tokens and apps ( that a user will use to access api with ) ?

Mostly yes, I suppose, but once again, it depends on your specific use case. But from my experience it seems more like this :)

What is the preferred way to handle tokens once an associated account is changed, ie (password recovered) ?

Good question. I think it also depends on your specific use case and your strategy. I don't think GitHub invalidate all tokens if you changed password... but in some cases this might be a good idea. It depends on how much your users will be annoyed by it :)

Yeah, we support those bundles. And yeah, probably it's a good use case when you have to clean up password reset tokens on password change :)

Cheers!

Hey @Someswara-rao-J!

Hmm. Did you create an access token authenticator like we did? https://symfonycasts.com/screencast/api-platform-security/access-token-authenticator

If so, here is what I would do to debug:

A) After making the AJAX request to "log in", find the Symfony profiler for that request and open it (reminder: you can always go to /_profiler to see a list of the most recent requests to your site - and you can find the AJAX request you just made there. When you get to the profiler for that request, click on the "Security" tab. Does it show you as authenticated?

B) If it does NOT show you as authenticated, then look more closely at your access token authenticator system: make sure your ApiTokenHandler is being called, etc. If it DOES show that you are authenticated... but then future AJAX requests appear to be not authenticated, it means that you are "losing" authentication between requests.

There are a few things that could cause this:

1) If you have stateless: true on your firewall, this will happen. This is because this tells your firewall to NOT use session/cookie storage.
2) If your frontend and backend are on different subdomains this could happen. For example, if your API is api.example.com and your frontend is just frontend.example.com, by default, Symfony will create a cookie for api.example.com and (iirc) that will not be usable by your frontend. You can adjust your cookie domain in the Symfony settings if this is the cause
3) In some situations, if you've added some custom serialization logic to your User class, you can "lose" authentication on the 2nd request. If you check the logs on the first request after the successful login, you should see something like:

Cannot refresh token because user has changed

Let me know if this helps!