OAuth2 Token Administration#
OAuth Flow Support#
We support code grant type, or auth code flow, which enables a client application to obtain authorized access to protected resources like web APIs. The auth code flow requires an user-agent that supports redirection from the authorization server back to your application.
More background information about OAuth on Wikipedia
Tokens can currently be used by
PostMaster Mail Accounts
Web Service Invokers
New in version 6.4: It is now possible to use the tokens in :an Invoker.
An application registration is requried to access resources via OAuth2. Upon registration, you should receive:
Microsoft and IMAP/POP#
Microsoft has switch off basic authentication for IMAP and POP protocols and moved to “Modern Authentication” (which is OAuth 2.0 token based auth) This has many benefits and improvements:
OAuth access tokens have a limited usable lifetime
are specific to the applications and resources they are issued
can’t be re-used
An Example Microsoft App#
In our Blog, we outlined an example setup
Adding a Token#
Adding a token will generates a YAML configuration in the database. This file has a specific format depending upon the provider and can be exported, modified, and imported as needed by the configuration or for migration (see below). We include basic formatting templates for the email providers, Google and Microsoft. The configuration is all done comfortably in the web interface, and you may generate as many service tokens as needed for your accounts.
The system setting
HttpType must be https for production systems using external services like GMail and Office365.
You can set this using the command-line as follows:
[otrs@host ~]$ bin/otrs.Console.pl Admin::Config::Update --setting-name HttpType --value https
Alternatively, you can search for HttpType in the system configuration and set it there.
After configuration, it may be necessary to edit the endpoints manually, as the service provider can change the requirements at any time.
The following fields are needed:
A name for the token.
- Client ID
Your client id. (The public identifier.)
- Client secret
Your client secret. (The application’s own password.)
New in version 6.4.4:
- URL *
Enter the endpoints required for authorization, token, and token refresh.
Add the scope for the token.
The validity of the setting.
Shows the template that was used to create this OAuth2 token configuration.
Types of Notifications to be shown
- Expired token
Shows a notification for admins below the top menu if the OAuth2 token has expired.
- Expired refresh token
Shows a notification for admins below the top menu if the OAuth2 refresh token has expired.
Edit a Token#
You can edit the token at any time.
The template type is permanent once the token is saved.
It the token overview, it is necessary to manually request a new token upon token setup and as required by your service provider. You will receive front-end notifications as configured to inform you when the token or refresh token has expired.
In the notification area, you receive notifications if a token or refresh token has expired. Clicking the notification will send you to the administration module for renewal. You may then click on refresh to get a new token.
When a refresh token expires, you must generate a new one with your service provider.
Backup and Migration#
The option to overwrite settings only changes those settings of the same name.
Redirect URI: The redirect_uri for Znuny is built from the system variables in the following manner
New in version 6.4: Starting in this release, we’ve added a special switch to conform to Microsoft’s requirement for POP3 and OAuth2. This is pre-configured for the hosts listed in the Microsoft KBA. Hosts that need a separate info about authentication method and token (instead of both in one line) can be added to the system configuration option.
Most commonly needed for Office365.