User account configuration: manage sessions, automatic account deletion, device limits, and account locks
Clients have the ability to configure many of their user account settings in the CSR Admin. You can access them by selecting Settings from the top navigation bar and User Account Configuration from the left navigation bar.
Email Verification
You can enable email verification of user accounts by toggling the Email Verification setting.
When a user account has been created, if the user account was created using password verification (not social sign in provider like Google, Facebook, Apple, or third-party auth via OIDC) and the email verification flag is set to ON, then the system requires their email is verified before they are allowed to login. If Email Verification setting is ON and the user has not verified their email, then the user will be unable to login.
When verify email is enabled, a WebSocket event will be generated for VERIFY_EMAIL. You have the option of sending the email when you handle the WebSocket event or you can create an IFX integration that will send the email. Arc XP subscriptions will not send the email.
Email verification can be handled from CSR perspective and/or reader experience, please see Manage user accounts: CSR perspective and Manage user accounts: Reader experience for additional details. Once userâs email is flagged as verified, they will be able to access their account.
Active Sessions
In an effort to limit credential sharing, publishers can configure the number of active sessions for a given account. Older sessions will be invalidated in a first in, first out basis. Sessions are validated when the token is refreshed.
On the User Account Configuration page below the Active Sessions section there is a drop down where you can configure the number of active sessions each user is allowed.
User Sign-in Expiration
The amount of time that users can remain logged in via a persistent session without having to resubmit their login credentials is also configurable. There are two types of session tokens that Arc uses for access control. This way you can have strongly-authenticated sessions which expire fast, and weaker-authenticated re-creatable sessions.
The refresh token is configurable and is created when users first log in and then invalidated when the TTL expires. You can configure the amount of time the refresh token is valid by updating the value in the User Sign In Expiration drop down. Changes to the User Sign In Expiration setting apply to users that log in after the updated has been made and prior created tokens will be updated at TTL expiration.
| Session Tokens | Time To Live | Description & Use |
|---|---|---|
| Access Token | 15 Minutes | Refresh take place in the background so customers can stay logged in based on a valid refresh token |
| Refresh Token | Configurable Default: 365 days | Controls the frequency that customers must re-login and provides a remember-me experience for the reader. If not using the SDK: When the access token expires call POST /identity/public/v1/auth/token to request the new access token |
access-token and refresh-token are returned during Sign up and/or login.
Revoking user sessions
Active user sessions need to be revoked when there is an attack on user accounts, a password is changed or an account is removed. This will require the user to login with their current or new password and ensures that bad actors cannot gain control of accounts.
We offer multiple methods for revoking session tokens.
- In the Customer Service Admin application there is a button in the Account Access tab to revoke all user session tokens.
- A Developer API Is available to complete a bulk session revocation on all accounts that may have been compromised.
Account Lock Out
In order to keep user accounts safe, you can configure the number of times fail logins are attempted before the account is locked out. A locked out user is blocked from logging in for a set period of time.
You can configure the amount of failed login attempts by changing the value in the Account Lock Out drop down. You can also set the time a user must wait before they are able to log in again.
If the account is locked, a CSR can manually unlock it without needing to wait for the automatic unlocking process.
Account Deletion
Requests for account deletion can come from users directly through an online request, by contacting customer service representatives, through a developer api or from automated systems. You also have the ability to configure rules for deleting accounts that have never been used or that have been inactive for a set period of time. For all deletion options, you can check to confirm that no active subscriptions exist and all critical financial and tax information is anonymized. The user must contact support to cancel the subscription prior to the account deletion.
The deletion process consists of a request to delete the account and then approval or rejection. The user makes a request to a customer support representative from an account management UI or from an automated system. The approval step is automatic if the request comes from an automated system but must be manually approved if made by a user. A customer support manager can manually approve the request in the Requests tab, or a user can approve the request by responding to a notice sent to their email.
After the deletion is requested, a Pending Approval status appears in the user profile overview. After the deletion has been approved and completed, the system removes the account and anonymizes all financial records. This is a permanent action and cannot be undone.
Automatic Account Deletion
It is not always valuable to keep accounts that have never been accessed, and, in some cases, it is required to remove accounts that have been inactive for a significant amount of time. You can automate the removal of inactive accounts, and you can configure the timing and number of messages in the Settings admin. This can be enabled by toggling the flag beneath the Automatic account deletion section.
The configuration options appear after you turn this option on. Then you can set the number of days and contact message attempts.
Deletion timing can be configured separately for idle accounts and ones that are unused. Idle accounts include ones where the user has not logged in for the set number of days but had previously been active. Unused accounts have never had a log in or the email was never verified.
For all deletion options, you can check to confirm that no active subscriptions exist and all critical financial and tax information is anonymized. Remember, these are permanent actions and cannot be undone.
Deleting Idle Accounts
For idle accounts, a number of contact attempts can be set to message the user and ensure the account should be removed. The contact attempts are sent by Arc as WebSocket events ACCOUNT_DELETION_NOTIFICATION with the account owner information and details of the impending deletion. The events can be used to create notifications informing the user that the account will be deleted if no login or action is completed.
Once this feature is enabled any account whose last logged in is higher than X days (âXâ corresponds to âdays of idle timeâ ) will start to be notified. Unused accounts have never had a log in or the email was never verified will start to be notified if these accounts have been created for more than Y days (Y corresponds to âdays before deleting unused accountâ).
For idle accounts, âDays of idle timeâ is basically the time from which the notifications will start going out notifying the account will be deleted. Thus, once the end-user has received the first notification, the account will be deleted in the next âcontact attemptsâ * (7-weekly or 30-monthly) days. The user will receive as many notifications CSR had defined in âcontact attemptsâ.
Deleting Unused Accounts
For unused accounts, accounts that have never had a log in or the email was never verified, once they receive the first notification, if the user doesnât take any action, the account will be deleted in the next 7 days.
Unused accounts do not have notification settings and will be deleted after the set time.