API Reference Charon v0.0.3-alpha
modules
Modules
Behaviour for an authentication challenge module.
An auth challenge that is meant to implement "do not ask for MFA again on this machine" functionality. Setting up the challenge results in a "bypass token" that the client can store, and can be used to complete the challenge. This challenge cannot be disabled for individual users. Clients should simply offer users an option to set it up or not, for the current device.
Auth challenge implementing a standard user password using a Comeonin-compatible hashing module. This challenge cannot be disabled for individual users, every user MUST have a password.
TOTP-challenge for which the answer has been sent to the user by SMS/email.
Basically the same as Charon.AuthChallenge.TotpChallenge
but with a longer default period (5 minutes).
An auth challenge implementing MFA recovery codes. Setting up the challenge results in a list of codes for the user to store.
TOTP-challenge. The otp codes may be generated by the user's device, or can be sent in advance by SMS/email.
An authentication flow that can be used to log in. A flow consists of stages, each of which has to be passed in order to log in. A stage consists of challenges, one of which has to be passed in order to pass the stage.
A stage in an authentication flow. A stage consists of challenges, one of which has to be passed in order to pass the stage.
Config struct. Keys & defaults
A session.
Tokens to be communicated to the client.
Plugs to create, update/refresh and delete sessions. When creating or updating a session, new tokens are created as well.
Behaviour definition of a persistent session store. The implementation is expected to handle cleanup of expired entries.
A persistent session store based on Redis, which implements behaviour Charon.SessionStore
.
In addition to the required callbacks, this store also provides get_all/2
and delete_all/2
(for a user) functions.
Session keys slowly accumulate in Redis when using this store.
It provides a cleanup/1
that should run periodically.
Behaviour for token-signing modules.
The default and most simple form of self-signed tokens, JWTs with symmetric-key signatures. These are suited for everything but OpenID Connect implementations, because these require third parties to verify the token signature, which requires assymetric keys.
The plugs in this module (and its submodules) can be used to verify tokens. The token's presence, signature, expiration and any claims can be checked. Additionally, the token's session can be loaded and, in case of a refresh token, it can be verified that it matches the session.
After verifying everything you would want to verify about a token, assign the following to the conn
Utility functions, mainly getters and setters for module internals.