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 OAuth2/OAuth1 default authentication and authorization flow against an "app". The developer will need to create this "app" with the service. By doing this, for OAuth1 information such as "client ID"/"consumer key" and "client secret"/"consumer secret" can be applied to the configuration.
When creating the app it is usually necessary to configure a call-back URL. You should use the following:
For OAuth2: /api/AuthorizedServiceResponse/HandleOAuth2IdentityResponse
For OAuth1: /api/AuthorizedServiceResponse/HandleOAuth1IdentityResponse
In addition, the package supports integration with OAuth1 or 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.
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.
Using a settings screen the administrator can review the service configuration.
Depending on the authentication method of the service,
OAuth1
OAuth2AuthorizationCode (default)
OAuth2ClientCredentials
ApiKey
The interface provides methods for retrieving the value of the access tokens or API key - GetOAuth1Token(), GetOAuth2Token() and GetApiKey(). 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.
Usage
Below you can learn more about how to use the Umbraco Authorized Services package.
Installation
The package should be installed into your Umbraco solution from NuGet.
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 usually 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.
Version 14.0.0 and up
The JsonSerializer configuration option was removed, as we will now use the CMS default based only on System.Text.Json.
Types related to this feature are also removed: JsonSerializerOption and JsonSerializerFactory.
Up to version 14.0.0
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.
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.
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:
Finally, 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.
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.
"twitter-oauth1": {"DisplayName":"Twitter with OAuth1","AuthenticationMethod":"OAuth1","ApiHost":"https://api.twitter.com","IdentityHost":"https://api.twitter.com","TokenHost":"https://api.twitter.com","RequestIdentityPath":"/oauth/authorize","RequestTokenPath":"/oauth/access_token","RequestTokenFormat":"FormUrlEncoded","RequestAuthorizationPath":"/oauth/request_token","AuthorizationUrlRequiresRedirectUrl":false,"UseProofKeyForCodeExchange":true,"ClientId":"","ClientSecret":"","Scopes":"","SampleRequest":"/1.1/account/settings.json"}
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.
