The Waypoint website is being redesigned to help you find what you are looking for more effectively.Join the Beta
Waypoint uses tokens to control access to the Waypoint server and bound the permissions of users, runners, and entrypoints. A handful of Waypoint endpoints are necessarily unauthenticated (including BootstrapToken and GetVersionInfo), but all endpoints that interact with users or applications (excepting authless triggers) require a valid token.
Tokens in Waypoint are base-58 encoded protobuf messages, and contain metadata including their kind, any associated entities that must be valid at auth time (users or runners), an expiration date, etc.
The Waypoint server does not store copies of the tokens it creates. Rather, it includes inside the token an HMAC of the token itself, signed with a private key known only to the server. Before authenticating a token, the server verifies the token's HMAC, preventing users from tampering with the contents of the token.
Tokens may be created with an expiration time, i.e. with the
-expires-in flag for
waypoint user token. After the expiration time is reached, the token cannot
be used to access the Waypoint server. If a token is created without an expiration
date, the token is valid forever.
Because the Waypoint server does not store Waypoint tokens, tokens cannot be directly invalidated. User tokens can be rendered useless by deleting the underlying user, and runner tokens can likewise be invalidated by rejecting the associated runner.
Invite tokens are short-lived tokens used to invite new users. The can
be created via
waypoint user invite. Invite tokens can be exchanged
for login tokens via the
The bootstrap token is the first token created by the Waypoint server during bootstrapping. It isn't a distinct token type, rather it's a user token associated with an automatically generated initial user. This user can be safely deleted once actual users have been created using the bootstrap token.
Login tokens are meant to be supplied to Waypoint users. They are meant to be used by users to authenticate requests made via the CLI and UI.
A user ID is encoded into Waypoint user tokens. Before authenticating a request, the Waypoint server verifies that the user associated with the ID exists (and has not been deleted).
Login tokens backed by valid users have full permission to access all Waypoint APIs.
Runner tokens a kind of Waypoint token issued to runners. They are
created by the
runner token command, and are automatically issued to
adopted runners. They are used by runners to accept and execute jobs.
Runner IDs and labels are also encoded into runner tokens. The server validates that the runner ID within the token is adopted or preadopted by the server, and the labels of the runner have not changed, before allowing requests.
Beyond these limitations, runner tokens have the same capabilities as login tokens.
A subset of login tokens, entrypoint tokens are meant for use by the Waypoint custom entrypoint.
As part of each deployment, the Waypoint runner will create a new entrypoint token
and make it available to the deployment process (generally via an environment variable
embedded in the platform's deployment spec). The Waypoint entrypoint uses this
to authenticate to the server and receive app configuration changes, commands
waypoint exec, communicate logs, etc.
Entrypoint tokens are only allowed on RPCs prefixed with "Entrypoint". As such, Entrypoint tokens cannot be used to manage users, generate new tokens, create deployments, etc.