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 2 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.
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.
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?
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.
