Skip to content

Users and groups

This page helps you create users, put them in groups, and decide what a client learns about them.

A user is a person who signs in. A group is a set of users: the permissions and attributes you give a group apply to every user in it, so you set them once instead of on each user.

  1. In the admin console, open Admin, Users and click Create new.

  2. Enter the user’s Email, and their Given name, Middle name and Family name if you like. Turn on Email verified if you know the address is theirs.

  3. Choose how the user gets a password:

    • Set password now, and type it in. Tell the user what it is.
    • Email the user a link to set up their password. The user chooses the password themselves, within 24 hours. This choice appears only when email is set up, under Email - SMTP.
  4. Click Create. The user’s page opens on its Details tab.

Users can also create their own accounts from the sign-in page: see Self-registration.

  1. Open Admin, Groups and click Create new.

  2. Enter a Group identifier, such as editors, and a Description.

  3. Leave Include group in access token if requested and Include group in id token if requested on if clients should see that a user is in this group. Click Create.

  4. Open the group’s Members tab, click Add member, search for a user, click Add to group and confirm with Yes.

Now give the group what its members need: permissions on its Permissions tab, and attributes on its Attributes tab.

Each user has a subject, a random identifier the auth server gives them when they’re created. It never changes, and it’s the sub claim in every token about them, so key your app’s records on it rather than on the email address, which can change.

The email address is the user’s sign-in name. Two users can’t share one, it’s stored in lowercase, and it’s at most 60 characters long.

Every new user gets the authserver:manage-account permission, which lets them manage their own account in the admin console’s Account pages. Nothing else: a new user holds no other permission and is in no group.

The user’s page has these tabs: Details, Profile, Picture, Email, Phone, Address, Authentication, Consents, Sessions, Attributes, Permissions and Groups. The profile, email, phone and address are what a client reads through scopes.

A disabled user can’t sign in. Turning off Enabled on the Details tab also ends every session the user has and revokes their refresh tokens, so no client can get a new token for them. Turning it back on lets them sign in again, and gives back nothing that was revoked.

Deleting a user deletes everything attached to them: their permissions, their group memberships and their attributes.

Set password on the Authentication tab gives the user a new password. It signs them out of every session and revokes their refresh tokens. A password the user changes themselves does the same, except for the session they change it from. See credential changes.

A user who forgot their password can ask for a reset link from the sign-in page: see Password recovery. The link you email a new user to set up their password is the same kind of link.

The Authentication tab also shows whether the user has two-factor authentication, and lets you turn it off for a user who lost their authenticator. They can set it up again under Account. If the device could be in someone else’s hands, end their sessions too: see A user who lost their authenticator.

A group identifier is 3 to 38 characters long. It starts with a letter, ends with a letter or digit, and uses only letters, digits, - and _, with no -- or __. A description is at most 100 characters.

A user can be in any number of groups. They hold every permission each of their groups holds, as well as their own. Deleting a group takes nobody’s account with it: its members just lose what the group gave them.

A group is listed in the groups claim when the client asks for the groups scope. Include group in access token if requested puts it in the access token, and Include group in id token if requested puts it in the ID token and in the /userinfo answer. Turn either off for a group a client has no business seeing.

An attribute is a key and a value you attach to a user or a group, such as department and sales. A client gets them in the attributes claim when it asks for the attributes scope.

  • A key is 1 to 38 characters long, with the same characters as a group identifier.
  • A value is at most 250 characters, and can’t contain < or >.
  • Include attribute in access token if requested and Include attribute in id token if requested work as they do for groups.

A user’s claim holds their own attributes and those of every group they’re in. When a user and one of their groups both have an attribute with the same key, the group’s value wins.

A user who holds one of the administrative permissions on the authserver resource, directly or through a group, is an administrator. So a group holding one makes every member an administrator, and adding a user to it, removing one, or deleting it needs authserver:manage, just as granting the permission directly does.

Goiabada also refuses any change that would leave no enabled user holding authserver:manage. Administrators has the whole rule, including the last administrator.