Updated audience validation for admin api tokens #10519
Conversation
no-issue This is a temporary solution until we implement token permissions based on actions upon objects, for example using canThis
allouis
changed the title
|
Cool that makes sense to me 👍 |
|
To clarify a little the why - we had lots of questions about what audience should be - should it include /ghost/? What about subdirectories.. should it be the full url? If I request a token for It was p clear that the validation in place was too strict, or at least had too many unconsidered edge cases. So, we talked about the purpose of audience, which is to narrow down what the token is for. The secret already ties a token to a specific site, so we use audience to tie a token to a specific API. This is futureproof against us having more APIs with similar auth in future. Method and resource based restrictions can be added later, e.g. using claims. |
| const jwt = require('jsonwebtoken'); | ||
| const JWT_OPTIONS = { | ||
| algorithm: 'HS256', | ||
| expiresIn: '5m', | ||
| audience: endpoint | ||
| audience: audience |
There was a problem hiding this comment.
@allouis FYI this is the v2 admin utility. No need to pass /admin/v2/ from tests.
no-issue
This is a temporary solution until we implement token permissions based on actions upon objects, for example using canThis