Considering the limited use case for this oauth2 server would involve use with a personal web server and access to home network IOT devices for a limited number of friends or family, it was not necessary to build an administration API. To perform management of user accounts, a simple form editor was incorporated directly in to the authorization server. Comprehensive user data including contact information was not included in the user records over privacy considerations. Access to the admin editor requires a user account with role "user.admin". The Admin Editor can be opened on the authorization server at the following path:

/panel/menu

In the case where the authorization server is operating in a development environment in demonstration mode, the user database is emulated using RAM memory variables. The Admin Editor will display a warning indicating this as shown in the screen capture below. In this mode, editing of accounts will function, but any edit of accounts will be lost when the server is shut down.

Alternately, when the server is configured to use a PostgreSQL database, the user account and client account records are stored in PostgreSQL database tables.

This screen capture shows the form used to edit user account records. A similar form is used to create new user records. The subsequent table explains each user property and it's use.

Property	Type	Description
id	V4 UUID	Unique identifier for the user record. The value is generated automatically. It is not editable after the record is created.
number	Integer ( > 0)	Secondary user identifier. The value is checked for uniqueness when the record is created. It is not editable after the record is created. This was added for purpose of compatibility with an existing database
Name	String	Real name of user. Allowed characters: abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890.-_@
username	String	The unique username used in the login form along side password. Allowed characters: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890.-_@; It is not editable after the record is created.
password	String	User's password used in the login form. Users password is stored as plain text in development configuration Users password is hashed using bcrypt when used with postgresql storage.
loginDisabled	Boolean	Disabled = true (checked). Disallow token issuance and validation of token with same username Disallow user password login and password changes Note: This does not invalidate any cookie or session authentication state. Disabled account would prevent future access to admin editor, but not remove current access as long as cookie and session are valid.
role	Array of String	The user role represents a scope value for access to a resource server. See the Scope section. This should be entered in the editor form as comma separated strings without quotes. Example: api.read, user.password Allowed Characters: abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890.,_

In the above section, user accounts are used to delegate permissions to a person. Client accounts are used to delegate permissions to a server or other network resource. For example, during login, a user will present his username and password to get an authorization code. The web server then will use the clientId and clientSecret to exchange the authorization code for an access token. The server client account would require some type of permission to request tokens, in addition to permissions of the user account. Client accounts for a REST API would need permission to validate access tokens using the authorization server API, but a REST API may be restricted from requesting new access tokens.

This screen capture shows the form used to edit client account records. A similar form is used to create new client account records. The subsequent table explains each client property and it's use.

Property	Type	Description
id	V4 UUID	Unique identifier for the client record. The value is generated automatically. It is not editable after the record is created.
Name	String	Descrptive Name of the client account When trustedClient is set to false, the client name will display on the confirmation dialog for access to specific resource. Allowed characters: abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890.-_@
clientId	String	The unique client id used to form credentials for authorization. Allowed characters: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890.-_@ It is not editable after the record is created.
clientSecret	String	A password type string used to form credentials for authorization. Client secret stored as plain text in development configuration Client secret is encrypted using crypto-js/aes with postgresql storage. Visible in editor when OAUTH2_EDITOR_SHOW_CLIENT_SECRET=true
trustedClient	Boolean	Trusted = true (checked). When set to true, the oauth2 workflow will present the user with a confirmation dialog to confirm permission for a specific resource. When set to false, the oauth2 workflow will proceed directly to authorization code.
allowedScope	Array of String	The client allowedScope represents a scope value for the server using the client account. See the Scope section. This should be entered in the editor form as comma separated strings without quotes. Example: api.read, auth.token Allowed Characters: abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890.,_
allowedRedirectURI	Array of Strings	During the oauth workflow for code grant or implicit grant, the user web browser submits the redirect URI. The redirectURI is used to designate the return address after the authorization server completes authentication of the user. In order to prevent submission of malicious redirectURI addresses from the user web browser, the authorization server maintains a list of allowed addresses for each client account. This is not applicable to grant types client grant and password grant and would be left blank. A mismatch will generate an error and the workflow will fail. This should be entered in the editor form as comma separated strings without quotes. Example: http://localhost:3000/login/callback, http://www.example.com/login/callback Allowed Characters: abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890:,"\'/%._-?&
clientDisabled	Boolean	This setting will disable a client account when set to client.clientDisabled=true. This will deny access to server-to-server API routes requiring authentication Basic Auth with base64 encoded client credentials in the authorization header including: POST /oauth/token /oauth/token/revoke /oauth/introspect. This will deny access to oauth2rise callback functions for browser accessible routes like /dialog/authorize Note: Not shown in above screen capture (TBD needs update)

The authorization server contains some counters that can be viewed in the admin editor.

This function will remove all access-tokens and refresh-tokens from the database. All remote web servers and resource servers will need to obtain new tokens to continue access. Authorization server stored sessions are also cleared, requiring users to login to the authorization server with a username and password. Note: Sessions and cookies of remote web servers are not impacted, however, stored tokens on these remote web servers will have been revoked.

This program does not support the capability of a user to view, modify or delete their own user record.

If a user account has been assigned role "auth.password" or "auth.admin" the user will be able to change their own password using the "/changepassword" route on the authorization server.