Sharing the internal ID of a user with the user himself is not considered a bad practice, many apps do it. Relying on the secrecy of such an ID is, especially if it is autoincremented. This is called security through obscurity.
Would it be a good idea to send the user id (primary autoincrementing token in my mySQL database) of an account when authenticating with user token? (Happens on each get/post)
This can work, but be aware of the checks you need to make on the server side.
For identification and authentication
- Make sure the user ID exists in your app
- Make sure the token is valid
- Make sure the token belongs to the user id passed with the request
- Make sure the user, who is now authentication, has access to the requested resource
I thought it might significantly increase performance when checking for authencity of the token? What do you guys think? Does it reduce security? Is this common practice?
Depending on what authentication scheme you use, you may need to hit the DB anyway. The performance gain if any depends on your use-case. Generally, I would avoid premature optimization. Build the app, measure your bottleneck and if it ever looks like the authentication, authorization needs speeding up, that's when you start thinking.
For your use-case, I would probably go with JWT tokens, where you can encode the user id inside the token. This will take care of the identification and authentication part: as only you can issue such tokens, and the token content cannot be tampered with. Beware, JWT has some limitations when dealing with session management and you still need to deal with authorization!
For alternative authentication methods take a look at the Web Authentication Guide I compiled a while ago.