| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
If a grant does not have a role, we should not go and make one up.
While not very useful for XMPP if you can't even login, it may be useful
for OAuth2/OIDC.
|
| |
|
|
|
| |
Such a session triggers errors in module:may or other places since it is
generally expected that a session must have a role.
|
| |
|
|
|
|
| |
Fixes parsing of tokens that happen to have a `;` in their secret part,
otherwise it splits there and the later bit goes into the username and
hitting the "Invalid token in storage" condition.
|
| |
|
|
|
|
|
|
| |
Some tokens, e.g. OAuth2 refresh tokens, might not have their lifetime
explicitly bounded here, but rather be bounded by the lifetime of
something else, like the OAuth2 client.
Open question: Would it be better to enforce a lifetime on all tokens?
|
| |
|
|
| |
We probably want to refactor revoke_token() to use this one in the future.
|
| | |
|
| | |
|
| |
|
|
|
| |
By checking the password_updated_at for non-nilness before using it,
we avoid a nasty crash :-).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This is another iteration on top of the previous sub-tokens work. Essentially,
the concept of a "parent token" has been replaced with the concept of a
"grant" to which all tokens now belong. The grant does not have any tokens
when first created, but the create_token() call can add them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Properties of sub-tokens:
- They share the same id as their parent token
- Sub-tokens may not have their own sub-tokens (but may have sibling tokens)
- They always have the same or shorter lifetime compared to their parent token
- Revoking a parent token revokes all sub-tokens
- Sub-tokens always have the same JID as the parent token
- They do not have their own 'accessed' property - accessing a sub-token
updates the parent token's accessed time
Although this is a generic API, it is designed to at least fill the needs of
OAuth2 refresh + access tokens (where the parent token is the refresh token
and the sub-tokens are access tokens).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Errors in sha256 becasue `token_secret` is nil since it was not passed
to _get_validated_token_info().
Looks like a simple oversight in ebe3b2f96cad
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new format has the following properties:
- 5 bytes longer than the previous format
- The token now has separate 'id' and 'secret' parts - the token itself is no
longer stored in the DB, and the secret part is hashed
- The only variable length field (JID) has been moved to the end
- The 'secret-token:' prefix (RFC 8959) is now included
Compatibility with the old token format was not maintained, and all previously
issued tokens are invalid after this commit (they will be removed from the DB
if used).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
RFC 6120 states that
> If the initiating entity does not wish to act on behalf of another
> entity, it MUST NOT provide an authorization identity.
Thus it seems weird to require it here. We can instead expect an
username from the token data passed back from the profile.
This follows the practice of util.sasl.external where the profile
callback returns the selected username, making the authentication module
responsible for extracting the username from the token.
|
| |
|
|
| |
`type(x ~= y)` is always a string, thus truthy
|
| | |
|
| |
|
|
|
| |
This is designed for use by other modules that want to accept tokens issued
by mod_tokenauth, without duplicating all the necessary logic.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This allows tokens to be tied to specific purposes/protocols. For example, we
shouldn't (without specific consideration) allow an OAuth token to be dropped
into a slot expecting a FAST token.
While FAST doesn't currently use mod_tokenauth, it and others may do in the
future. It's better to be explicit about what kind of token code is issuing or
expecting.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is a security improvement, to ensure that sessions authenticated using a
token (note: not currently possible in stock Prosody) are invalidated just
like password-authenticated sessions are.
|
| |
|
|
|
|
|
|
|
|
|
| |
These changes to the API (hopefully the last) introduce a cleaner separation
between the user's primary (default) role, and their secondary (optional)
roles.
To keep the code sane and reduce complexity, a data migration is needed for
people using stored roles in 0.12. This can be performed with
prosodyctl mod_authz_internal migrate <host>
|
| |
|
|
|
|
| |
This also updates the module to the new role API, and improves support for
scope/role selection (currently treated as the same thing, which they almost
are).
|
| | |
|
| | |
|
| |
|
