New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for app specific tokens #6559
Comments
We discussed this idea while investigating: matomo-org/matomo-mobile-2#5275 - see also two factor auth which would benefit #2846 |
Currently users have some issues with the fact that the Use case
Would this use case be met with App Specific passwords?Could App specific passwords also help with this use case above? @sgiehl maybe you can confirm whether App-specific password would help here and if so, how would it be scripted by calling the API? |
If we implement the app specific passwords as kind of additional token_auths for a user the api would be called as usual, but as token_auth a app specific password would be given. So it would match your use case |
|
App specific passwords won't "fix" this problem. Eventually, app specific passwords will replace token_auth from user table. For each different app you want to access the API, you create an app specific password. This password or token will be only shown once and afterwards securely stored and surely we won't be able to return it in clear text in API or UI for security.
While it will be for sure useful to assign read-only / read-write (like view / admin) access to app specific passwords, this won't fix the use case you are describing. You are still giving away the token to view all data etc. They could already now create a user with view access, and use the token to embed the iframe. And you can get the token from the API if you have the users original password. |
Fix matomo-org/matomo-mobile-2#5404 Not writing a test for it as I'm removing this API method as part of #6559 anyway.
* Support email address in getTokenAuth Fix matomo-org/matomo-mobile-2#5404 Not writing a test for it as I'm removing this API method as part of #6559 anyway. * Update API.php
* Support email address in getTokenAuth Fix matomo-org/matomo-mobile-2#5404 Not writing a test for it as I'm removing this API method as part of matomo-org#6559 anyway. * Update API.php
* Support email address in getTokenAuth Fix matomo-org/matomo-mobile-2#5404 Not writing a test for it as I'm removing this API method as part of matomo-org#6559 anyway. * Update API.php
It would be great if a user could create app specific passwords and revoke them if needed.
For instance you might want to create a new app specific password for each device when using the mobile app. If you ever lose a device (phone) you can simply revoke the password that you have used for this device but all other passwords would be still valid.
You do not want to create a new user for the mobile app with a different password as you would have to sync/change the dashboards and ViewDataTable params for each user. Once we implement features like "Continuity" one would still benefit of those features. With "Continuity" I mean when opening the mobile app it could open the same website and report that you have accessed last on the desktop although different passwords are used etc. This would not be possible if someone had to create multiple users for each device.
You might also want to generate app specific passwords for different servers that talk to the Piwik HTTP API etc.
It will be also useful if we ever generate 2-factor authentication.
App specific passwords would consist of an App name (eg PiwikMobileApp, or PythonClientWhatever), a device (eg PhoneXYZ or ServerXYZ) and a generated password. This password would be ideally quite long, eg 16 characters. Before someone can generate a new specific app password we should ask him for his actual password and only generate / or only let him manage his app passwords if the actual password is correct.
Some systems that do support app specific passwords would not let you log in into the browser version (meaning regular Piwik login) with an app specific password but we would probably still do?
The text was updated successfully, but these errors were encountered: