View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010172 | Taler | merchant backend | public | 2025-07-09 16:55 | 2025-07-09 20:37 |
| Reporter | sebasjm | Assigned To | sebasjm | ||
| Priority | normal | Severity | major | Reproducibility | have not tried |
| Status | feedback | Resolution | open | ||
| Summary | 0010172: should not be able to create to create tokens with a token | ||||
| Description | This works, and I can use the token returned to create more tokens (on any scope) $ curl 'http://merchant.taler.test/private/token' -H 'Authorization: Bearer secret-token:GVP8MZ2R22XGNY1KA9Q72RVMHZZ0E7K35E924ZJQECJTT0TFQ6NG' --data-raw '{"scope":"all","duration":{"d_us":"forever"}}' { "access_token": "secret-token:H6QTCSWAD2458EDG09J3JCH98N63ARM0SCXKG4EM3PMP6W942CP0", "token": "secret-token:H6QTCSWAD2458EDG09J3JCH98N63ARM0SCXKG4EM3PMP6W942CP0", "scope": "all", "refreshable": false, "expiration": { "t_s": "never" } } The problem is that this is the normal token used by the merchant SPA. I think we should either have a special scope for tokens to create new tokens (1) or only allow the creation of tokens with Basic, not Bearer (2). I think (2) is the simplest and safest. We can also go for (1) for a "spa-session" scope. This allows the full management (like all) but prevents the creation of new tokens if leaked. | ||||
| Tags | No tags attached. | ||||
|
|
You should not be able to create a token with a broader scope than the one you present. I also though it had to be refreshable. Need to check the code. |
|
|
What is the "normal token used by the SPA"? Because we do not have a scope for that, so I guess you already have a scope with "all". So your description would not be correct. We can define a special scope for SPAs, if you can provide me with a clear requirement and set of permissions required. |
|
|
(Note: "all" always was and still is defined as "can do anything including refresh") |
|
|
We cannot limit the token endpoint to only Basic, because that is what ":refreshable" is about. |
|
|
Your proposal (1) also does not work, because you can request scope "spa-session:refeshable" and get a token that can be refreshed. |
|
|
The SPA clearly should ask for a non-refreshable token, possibly with a lifetime restriction that the user can configure on login. When the SPA is used to create *another* token for export, I think it makes sense for the SPA to require the user to re-enter username/password for this. Maybe this is a pure SPA issue and not something that requires changes in the backend? |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-07-09 16:55 | sebasjm | New Issue | |
| 2025-07-09 17:03 | Christian Grothoff | Assigned To | => schanzen |
| 2025-07-09 17:03 | Christian Grothoff | Status | new => assigned |
| 2025-07-09 18:07 | schanzen | Note Added: 0025469 | |
| 2025-07-09 18:09 | schanzen | Note Added: 0025470 | |
| 2025-07-09 18:11 | schanzen | Note Added: 0025471 | |
| 2025-07-09 18:12 | schanzen | Note Added: 0025472 | |
| 2025-07-09 18:12 | schanzen | Note Added: 0025473 | |
| 2025-07-09 20:37 | Christian Grothoff | Note Added: 0025474 | |
| 2025-07-09 20:37 | Christian Grothoff | Assigned To | schanzen => sebasjm |
| 2025-07-09 20:37 | Christian Grothoff | Status | assigned => feedback |
