Service accounts

Accounts that other systems sign in with to use the router's services, such as an OpenTelemetry Collector reading the router's metrics. They cannot sign in to the Manager.

Columns

Name: a GUID, which Add proposes, or a user name.
Kind: a service account, or Internal: the router creates and manages an internal one for its own services, so it has no actions here.
OpenID Provider:
- as a client: the number of redirect URIs and the allowed groups, the grants, public, and the scopes it asks for;
- as a resource: its scopes and roles;
- - for none.

Actions

Add and Edit: the display name, the description, an optional e-mail address and the OpenID Provider settings, as a client and as a resource; Add also takes the password.
Password, Disable, Enable, Unlock after failed logins, and Remove.

OpenID Provider

The router can sign its users in to other systems with OpenID Connect. Its issuer and discovery URL are on the Addresses panel of the Overview, each with a copy icon, and while it is enabled the title of the list has the number of its clients. It is turned on on the router as root:

vpn-config-edit set --restart oidc.enabled true

As a client

A service account with a redirect URI or a grant is a client:

Client ID: the account's name.
Client secret: the account's password.
Redirect URIs: where the provider sends the browser back after a sign-in; https, or http for localhost, on any port. One per line. They give the client the authorization code flow with PKCE (S256).
Post-logout redirect URIs: where the browser may go after signing out. One per line.
Allowed groups: only their members may sign in to the client; without any, every user may.
Client credentials: the client gets a token as its own service account, with its secret and without a user, for jobs and scripts.
Device authorization: a program without a browser shows a code. The user opens the router's device page, enters the code, signs in, and allows or denies the program.
Public client (no secret): for programs that cannot keep a secret, such as a CLI; it cannot use client credentials.
Client scopes: the scopes of resources the client may ask for, as <resource>:<scope>.

Users sign in on the router's page with their password and code, or with a passkey.

As a resource

Every service account is also a resource: an application that checks the router's tokens, such as an S3 gateway. A client asks for a token for it by its name, or by asking for its scopes.

Scopes: what clients may ask to do there, such as read, asked for as <name>:read. A scope a client may ask for cannot be removed.
Roles: names such as Reader, each assigned to groups, users and service accounts. A token for the resource carries, in roles, the roles its user or service account holds, directly or through a group.

The tokens are signed JWTs, which the resource checks with the provider's keys. The access token names the resource as its audience, and carries the scopes granted and the roles. The ID token, for the client, carries the user's roles of the client itself.

3.2 KiB Raw Blame History