Details a package supporting creation of integrations with external services that use an OAuth flow for authentication and authorization.
Umbraco Authorized Services is an Umbraco package designed to reduce the effort needed to integrate third-party services into Umbraco solutions. Many Software as a Service (SaaS) offerings require an OAuth or API key based flow for authentication and authorization. Working with them requires a fair bit of plumbing code to handle creating an authorized connection. This is necessary before the developer working with the service can get to using the provided API to implement the business requirements.
There are similarities to the flow that needs to be implemented for different services. Steps include:
Redirecting to an authentication endpoint.
Handling the response including an authentication code and exchanging it for an access token.
Securely storing the token.
Including the token in API requests.
Serializing requests and deserializing the API responses.
Handling cases where the token has expired and obtaining a new one via a refresh token.
With API key based flows, the process is a little simpler. But you still have to consider secure storage of the key, providing it correctly in API calls and handling serialization tasks.
There are also differences across the request and response structures and variations in the details of the flow itself.
The package tries to implement a single, best practice implementation of working with OAuth. For particular providers the specific flow required can be customized via configuration or code.
The primary use case for this package is when working with services that offer an OAuth authentication and authorization flow against an "app". The developer will need to create this "app" with the service. From this, details such as client key and secret can be obtained and applied to the configuration.
In addition, the package supports integration with Api key based authentication and authorization services.
Features
For the solution developer, the Umbraco Authorized Services offers two primary features.
Authorized Services in the backoffice
Firstly there's a tree available in the Settings section of the backoffice, called Authorized Services. The tree shows the list of services based on the details provided in configuration.
Each tree entry has a management screen where an administrator can authenticate with an app that has been setup with the service. The status of each service is shown on this screen. When authorized, the authentication and authorization flow has been completed and an access token stored.
A service can be configured to allow the manual entry of access tokens/API keys manually using the CanManuallyProvideToken or CanManuallyProvideApiKey settings. If this is set to true, a new section will be available for providing them.
From the settings panel the administrator can review the service configuration.
IAuthorizedServiceCaller interface
Secondly, the developer has access to an interface - IAuthorizedServiceCaller - that they can inject instances of and use to make authorized requests to the service's API.
Package Links
Usage
Below you can learn more about how to use the Umbraco Authorized Services package.
Installation
App Creation
Services supported by the package will often offer an OAuth authentication and authorization flow against an "app" that the developer will need to create. This will make available information, including for example a "client ID" and "client secret", that will need to be applied in configuration.
When creating the app it will be necessary to configure a call back URL. You should use the following:
For OAuth2: /umbraco/api/AuthorizedServiceResponse/HandleOAuth2IdentityResponse
For OAuth1: /umbraco/api/AuthorizedServiceResponse/HandleOAuth1IdentityResponse
Configuring a Service
Details of services available need to be applied to the Umbraco web application's configuration.
An example of doing this through the appSettings.json file is shown below. Other sources such as environment variables can also be used, as per standard .NET configuration.
TokenEncryptionKey is a setting for an optional key used for token encryption when they are saved and retrieved from storage. It's only necessary and advisable when using the non-default AesSecretEncryptor implementation.
Services contains the a collection of details for all the configured services structured as a dictionary.
The dictionary key is the alias of the service, which must be unique across the service collection.
The following table describes each of the service elements. Where appropriate, an example is provided for one service provider, GitHub.
Not all values are required for all services. Those that are required are indicated below.
Element
Description
Required?
Example
DisplayName
Provides a friendly name for the service used for identification in the user interface.
Yes
CanManuallyProvideToken
Toggles an UI section in the backoffice for manually providing an access token.
No
CanManuallyProvideApiKey
Toggles an UI section in the backoffice for manually providing an API key.
No
CanExchangeToken
Specifies whether the access token can be exchanged with a long lived one.
No
ExchangeTokenProvision
The available options for exchanging an access token. Configuration includes: TokenHost, RequestTokenPath, TokenGrantType, RequestRefreshTokenPath, RefreshTokenGrantType and ExchangeTokenWhenExpiresWithin
No
AuthenticationMethod
An enum value that controls the type of authentication. OAuth2AuthorizationCode is the default value; other available options are OAuth2ClientCredentials, OAuth1 and ApiKey.
No
ClientCredentialsProvision
The available options for providing credentials in an OAuth2 flow: AuthHeader or RequestBody.
No
ApiHost
The host name for the service API that will be called to deliver business functionality.
Yes
https://api.github.com
IdentityHost
The host name for the service's authentication endpoint, used to initiate the authorization of the service by asking the user to login.
Yes
https://github.com
TokenHost
Some providers make available a separately hosted service for handling requests for access tokens. If that's the case, it can be provided here. If not provided, the value of IdentityHost is used.
No
RequestIdentityPath
Used along with IdentityHost to construct a URL that the user is redirected to when initiating the authorization of the service via the backoffice.
Yes
/login/oauth/authorize
AuthorizationUrlRequiresRedirectUrl
Some providers require a redirect URL to be provided with the authentication request. For others, instead it's necessary to configure this as part of the registered app. The default value if not provided via configuration is false.
No
RequestTokenPath
Used, along with TokenHost to construct a URL used for retrieving access tokens.
Yes
/login/oauth/access_token
RequestTokenFormat
An enum value that controls how the request to retrieve an access token is formatted. Options are Querystring and FormUrlEncoded. Querystring is the default value.
No
RequestAuthorizationPath
OAuth1 flow path for building the authorization URL.
No
JsonSerializer
An enum value that defines the JSON serializer to use when creating requests and deserializing responses. Options are Default and JsonNet and SystemTextJson as described below. If not provided, Default is used.
This flag indicates whether the basic token should be included in the request for an access token. If true, a base64 encoding of <clientId>:<clientSecret> will be added to the authorization header. Default is false.
No
ApiKey
Provides the service's API key, if "AuthenticationMethod": "ApiKey"
No
ApiKeyProvision
Provides an object that dictates how the API key will be included with each request. This is configured using the Method(pass the API key as QueryString or HttpHeader) and Key (name of the key used to include the API key) properties. You can also provide additional parameters that will be included in the querystring or headers via the AdditionalParameters dictionary.
No
ClientId
This value will be retrieved from the registered service app. For OAuth1 registered apps, the matching value is consumer key.
Yes
ClientSecret
This value will be retrieved from the registered service app. As the name suggests, it should be kept secret and so is probably best not added directly to appSettings.json and checked into source control. For OAuth1 registered apps, the matching value is consumer secret.
Yes
Scopes
This value will be configured on the service app and retrieved from there. Best practice is to define only the set of permissions that the integration will need.
Yes
repo
IncludeScopesInAuthorizationRequest
Specifies whether the provided scopes should be included in the authorization request body.
No
UseProofKeyForCodeExchange
No
AccessTokenResponseKey
The expected key for retrieving an access token from a response. If not provided the default access_token is assumed.
No
RefreshTokenResponseKey
The expected key for retrieving a refresh token from a response. If not provided the default refresh_token is assumed.
No
ExpiresInResponseKey
The expected key for retrieving the datetime of token expiry from a response. If not provided the default expires_in is assumed.
No
SampleRequest
An optional sample request can be provided, which can be used to check that an authorized service is functioning as expected from the backoffice.
No
/repos/Umbraco/Umbraco-CMS/contributors
RefreshAccessTokenWhenExpiresWithin
Specifies a time interval for expiration of access tokens.
No
With UseProofKeyForCodeExchange set to true, a random code will be generated on the client and stored under the name code_verifier. Using the SHA-256 algorithm it will be hashed under the name code_challenge. When the authorization URL is generated, the code_challenge will be sent to the OAuth Server, which will store it. The next request for access token will pass the code_verifier as a header key. The OAuth Server will compare it with the previously sent code_challenge.
The options for JsonSerializer are:
Default - uses the Umbraco CMS default IJsonSerializer.
JsonNet - uses the JSON.Net serializer.
SystemTextJson - uses the System.Text.Json serializer.
In 14.0 the JsonSerializer configuration option was removed, as we will now use the CMS default based only on System.Text.Json.
Authorizing a Service
With one or more service configured, it will be available from the items within a tree in the Settings section.
Selecting an item will show some details about the configured service, and it's authentication status.
If the service is not yet authorized, click the Authorize Service button to trigger the authentication and authorization flow. You will be directed to the service to login, and optionally choose an account. You will then be asked to agree to the permissions requested by the app. Finally you will be redirected back to the Umbraco backoffice. You should see confirmation that an access token has been retrieved and stored such that the service is now authorized. If provided, you can click the Verify Sample Request button to ensure that service's API can be called.
Calling an Service
To make a call to an authorized service, you first need to obtain an instance of IAuthorizedServiceCaller. This is registered with the dependency injection framework. As such it can be injected into a controller, view or service class where it needs to be used.
When making a request where all information is provided via the path and querystring, such as GET requests, the following method will be invoked:
serviceAlias - the alias of the service being invoked (e.g. github).
path - the path to the API method being invoked (e.g. /repos/Umbraco/Umbraco-CMS/contributors).
httpMethod - the HTTP method to use for the request (e.g. HttpMethod.Get).
There is also a type parameter:
TResponse - defines the strongly typed representation of the service method's response, that the raw response content will be deserialized into.
If you need to provide data in the request an overload is available. This can be used for POST or PUT requests that trigger the creation or update of a resource:
There are convenience extension methods available for each of the common HTTP verbs. These allow you to simplify the requests and omit the HttpMethod parameter, e.g.
These will return null if the token or key is not found. They will also return null if the service is not configured to use the authorization method related to these objects.
Verified Providers
The following service providers have been tested against the package implementation. For each one the necessary configuration is listed.
As integrations with more providers are successfully completed, we plan to maintain the details for each here. Pull requests updating this list with verified integrations are welcome.
The Authorized Services package is open-source and we welcome Issues, suggestions for improvement, and PRs.
The readme file there contains further information, expanding on the documentation you have read here. This will help anyone interested in understanding how it has been developed and how to contribute to the solution.
