View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009556 | Taler | specification | public | 2025-02-17 18:14 | 2025-03-23 23:39 |
| Reporter | Florian Dold | Assigned To | schanzen | ||
| Priority | low | Severity | feature | Reproducibility | have not tried |
| Status | assigned | Resolution | open | ||
| Target Version | 1.1 | ||||
| Summary | 0009556: address merchant auth token weirdness | ||||
| Description | * The /token endpoint currently takes only a **Bearer** token as auth and returns another Bearer token. Instead, the /token endpoint should accept credentials via basic auth (and a Bearer token only when refreshing a token). * For human-picked passwords (that are not auth tokens!), we should not require the secret-token: prefix. That prefix should only be necessary for *actual* tokens, not for login credentials. * The response body isn't consistent with the bank (auth_token vs token). | ||||
| Tags | No tags attached. | ||||
|
|
"Instead, the /token endpoint should accept credentials via basic auth (and a Bearer token only when refreshing a token)." plus "For human-picked passwords (that are not auth tokens!), we should not..." Needs further clarification: Is the (/private/token) endpoint ONLY supposed to accept "human-picked" passwords (or refresh tokens)? Are there any other type of credentials? What kind of credential is the configured access token going to become? My working assumption is also that this mainly related to the slightly messy taler-merchant-httpd.c:1883ff code, is that right? (If yes, this will require some rework regarding a lot of security-critical logic.) |
|
|
The answers (until now) are: The instance has a password, which can be set, for example, with taler-merchant-passwd. This password can and must be used for /private/token requests to get an access token. The access token can be used on all the other (private) APIs. Open question: What about the /auth endpoint (https://docs.taler.net/core/api-merchant.html#post-[-instances-$INSTANCE]-private-auth). It seems to have special case handling. It would be treated like any other API, I think, but somebody thought something else here it seems... |
|
|
I just now realized that this change will require new testing cmds to retrieve the access tokens and probably most tests needs to be modified in order to reflect the change. |
|
|
Started working on this here https://git.gnunet.org/merchant.git/log/?h=dev/schanzen/issue_9556 |
|
|
We also may have to/want to invalidate all tokens issued before a new password is set! |
|
|
This change touches pretty much everything that uses merchant, including and inparticular the taler-typescript-core stuff. So while the implementation in the draft is pretty much good to go almost, my guess would be that this requires a lot more work across repos and integration tests. Things todo: - Rename JSON keys: token => password: token => access_token - Fix SPA to use access tokens instead of passwords - Fix Wallet to use access tokens instead of passwords (?) - Discard tokens on pw change 0009651 - Scope rework 0009647 - Update documentation, in particular https://docs.taler.net/core/api-merchant.html#authentication to reflect changes When all is good I will rebase and squash the branch into a single commit. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-02-17 18:14 | Florian Dold | New Issue | |
| 2025-02-17 18:14 | Florian Dold | Status | new => assigned |
| 2025-02-17 18:14 | Florian Dold | Assigned To | => Christian Grothoff |
| 2025-02-17 20:13 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2025-02-17 20:13 | Christian Grothoff | Status | assigned => confirmed |
| 2025-02-17 20:13 | Christian Grothoff | Category | mechant backend => specification |
| 2025-03-21 15:00 | schanzen | Relationship added | related to 0009646 |
| 2025-03-21 15:00 | schanzen | Assigned To | => schanzen |
| 2025-03-21 15:00 | schanzen | Status | confirmed => assigned |
| 2025-03-22 11:17 | schanzen | Note Added: 0024279 | |
| 2025-03-22 18:07 | schanzen | Note Added: 0024282 | |
| 2025-03-22 21:30 | schanzen | Note Added: 0024283 | |
| 2025-03-22 21:39 | schanzen | Note Added: 0024284 | |
| 2025-03-22 22:12 | schanzen | Note Added: 0024285 | |
| 2025-03-23 19:42 | schanzen | Relationship added | related to 0009647 |
| 2025-03-23 19:43 | schanzen | Relationship added | related to 0009651 |
| 2025-03-23 23:34 | schanzen | Note Added: 0024292 | |
| 2025-03-23 23:36 | schanzen | Note Edited: 0024292 | |
| 2025-03-23 23:36 | schanzen | Note Edited: 0024292 | |
| 2025-03-23 23:37 | schanzen | Note Edited: 0024292 | |
| 2025-03-23 23:38 | schanzen | Note Edited: 0024292 | |
| 2025-03-23 23:39 | schanzen | Note Edited: 0024292 |
