Accounts
Last updated
Last updated
An account represents somebody or something that needs to be identified. This can be a human user, a machine, an IoT device, or anything else we have not yet thought of. Other common terms representing the same would be "identity" or "user". At Quasr, we chose to primarily go with the term "account" to emphasize that those needing to identify themselves do not necessarily need to be human users.
This section allows you to manage the accounts in this tenant: see all accounts (these can be human users or machine clients) and manage them by creating, editing, deleting them from here. From the list view, you can delete, test (client accounts only) and view account details via the action icons.
User Settings allow you to manage:
Account Label: a meaningful name to easily distinguish between accounts
Status (Enabled, Disabled, Pending)
External: whether a user is an internal or external user; has affects on consent handling
Permissions: permissions granted to this user. See Controls for details.
Factor Enrollments: enrolled factors of this user. A tenant administrator cannot enroll additional or disable/delete factors on behalf of an external user (to avoid impersonation or conflict).
Consents: consents granted by this client. See Controls for details.
Client Settings allow you to manage:
Account Label: a meaningful name to easily distinguish between clients
Status (Enabled, Disabled, Pending)
External: whether a user is an internal or external user to your organization; has affects on consent handling
OAuth2 Settings: configuration specific to factors relying on the OAuth2 protocol (see below)
Rules: mappings of controls to this client (determines OAuth 2.0 scopes). See Controls for details.
Permissions: permissions granted to this client. See Controls for details.
Factor Enrollments: for accounts of type "client", these can be used for the client credentials grant
Consents: consents granted by this client. See Controls for details.
An account of type "client" can take the role of a relying party (RP) in OAuth2 and OpenID Connect terms, or can act as a subject or resource owner towards a resource server itself via Client Credentials Grant.
The OAuth2 Settings allow to configure the following relevant options:
Client ID: read-only, same as the account ID
Scopes: scopes that this client can be granted to (controlled using rules)
Allowed Grant Types: the OAuth2 grant types that this client is allowed to be used in
Allowed Response Types: allowed response types with the authorization code grant (code and/or id_token)
Login URL: the URL of the login page where the initial authorize call should lead the user to when using the authorization_code grant
Audience(s): audience(s) for the access token. Multiple audiences can be provided comma-separated.
Allowed Redirect URIs: allowed redirect URIs when using the authorization code grant
Access Token Expiration: default 1 day, max. 30 days
Refresh Token Expiration: default 1 week, max. 1 year
ID Token Expiration: default 5 minutes, max. 1 day
ID Token Extension: optional, allows to select a extension to inject custom claims into ID tokens
Access Token Extension: optional, allows to select an extension to inject custom claims into access tokens
Client Authentication: the way for this client to authenticate itself; can be set to either CLIENT_SECRET or NONE. Note, if "Allowed Grant Types" contains client_credentials, then this option must be set to CLIENT_SECRET and cannot be set to NONE.
Client Authentication Factor: the factor to be used for the client secret. This option only shows if "Client Authentication" is set to CLIENT_SECRET. You can either pick an existing enrollment of type "secret" (if existing) or let the system create a new one
