Conversation
supportI have a problem: I use api to work with android and ios applications. I have more than one application. I save tokens in the application and work with them so that I don’t have to log (to auth) in many times. If there is one application, then everything works perfectly, but if there are already two, then a problem arises. Authorization in any application destroys authorization in others because the refresh token is updated (is changed). I can solve the problem by saving the username and password on the device and logging in again each time, but this is a serious security blow that almost completely removes the meaning of using tokens (and I can’t using a few apps at the same time). How can I solve this problem? Maybe make multiple refresh tokens or not refresh refresh token on re-authorization? This topic was modified 5 years, 8 months ago by harchvertelol . This topic was modified 5 years, 8 months ago by harchvertelol . This topic was modified 5 years, 8 months ago by harchvertelol .
Yes I see your problem. This can be fixed by adding a new property to the login API endpoint. Now it accepts only username and password . But if a third property is allowed for example client_name then you can specify some unique value for this application. Then I can allow multiple access and refresh tokens for each combination of WP users / client_name value. Does this seem like a good solution? This reply was modified 5 years, 8 months ago by michielve .
I didn’t quite understand, but let’s try. An example would make it clearer. That is, I log in with the new parameter, and then I invoke the desired refresh token with this new parameter, right? That is, along with authorization and updating the token, I send an additional new parameter?
Let me show you an example: From your first application you login with the below JSON: {"username": "pete", "password": "123secret", "client_name": "app1"} And you receive: {"access_token": "token1", "refresh_token": "token2"} Now from another application you login into the same WP account, but with another “client_name”: {"username": "pete", "password": "123secret", "client_name": "app2"} And you receive another access and refresh token: {"access_token": "token3", "refresh_token": "token4"} At this point 2 pairs of access/refresh tokens are attached to your WP account. Not that this is different from how it works now, because currently the first pair is replaced by the second pair. The addition of the “client_name” makes it possible to keep a pair of access/refresh tokens for each application. So you could also add a third or fourth one. The other API endpoints stay the same.
How to invoke the refresh token? Send both refresh token and client name?
Just call {"token": "your_refresh_token"} as usual – refresh tokens are unique so no need to add the client name here.
What if two identical tokens are generated for different clients? If there are many clients and many applications, this can happen. This reply was modified 5 years, 8 months ago by harchvertelol .
That’s theoretically possible, but I don’t think it will happen. I haven’t looked into this in detail.
I still suggest making an additional parameter client name for the update token. Moreover, if this parameter is not set, then make it empty by default (for login and refresh token), this will preserve compatibility with all old versions. This reply was modified 5 years, 8 months ago by harchvertelol .
Good suggestion – I released a new version with client_name added to the login and refresh calls. BW
Thanks, I’ll be testing! UPDATE: Maybe it is worth adding an optional client name along with the authorization header to each request? This reply was modified 5 years, 8 months ago by harchvertelol .
For example: Authorization: hash;app_name
Hi, I’m keeping the Bearer token clean and simple with just the access token. This is also more in line with common OAuth2 implementations where you also only send the access token in de authorization header.
Yes I see your problem. This can be fixed by adding a new property to the login API endpoint. Now it accepts only username and password . But if a third property is allowed for example client_name then you can specify some unique value for this application. Then I can allow multiple access and refresh tokens for each combination of WP users / client_name value. Does this seem like a good solution? This reply was modified 5 years, 8 months ago by michielve .
I didn’t quite understand, but let’s try. An example would make it clearer. That is, I log in with the new parameter, and then I invoke the desired refresh token with this new parameter, right? That is, along with authorization and updating the token, I send an additional new parameter?
Let me show you an example: From your first application you login with the below JSON: {"username": "pete", "password": "123secret", "client_name": "app1"} And you receive: {"access_token": "token1", "refresh_token": "token2"} Now from another application you login into the same WP account, but with another “client_name”: {"username": "pete", "password": "123secret", "client_name": "app2"} And you receive another access and refresh token: {"access_token": "token3", "refresh_token": "token4"} At this point 2 pairs of access/refresh tokens are attached to your WP account. Not that this is different from how it works now, because currently the first pair is replaced by the second pair. The addition of the “client_name” makes it possible to keep a pair of access/refresh tokens for each application. So you could also add a third or fourth one. The other API endpoints stay the same.
How to invoke the refresh token? Send both refresh token and client name?
Just call {"token": "your_refresh_token"} as usual – refresh tokens are unique so no need to add the client name here.
What if two identical tokens are generated for different clients? If there are many clients and many applications, this can happen. This reply was modified 5 years, 8 months ago by harchvertelol .
That’s theoretically possible, but I don’t think it will happen. I haven’t looked into this in detail.
I still suggest making an additional parameter client name for the update token. Moreover, if this parameter is not set, then make it empty by default (for login and refresh token), this will preserve compatibility with all old versions. This reply was modified 5 years, 8 months ago by harchvertelol .
Good suggestion – I released a new version with client_name added to the login and refresh calls. BW
Thanks, I’ll be testing! UPDATE: Maybe it is worth adding an optional client name along with the authorization header to each request? This reply was modified 5 years, 8 months ago by harchvertelol .
For example: Authorization: hash;app_name
Hi, I’m keeping the Bearer token clean and simple with just the access token. This is also more in line with common OAuth2 implementations where you also only send the access token in de authorization header.