Protected content in the Delivery API
How to use member authorization with the Delivery API to access protected content.
Umbraco allows for restricting access to content. Using the "Public access" feature, specific content items can be protected and made accessible only for authorized members. The same is possible in the Delivery API.
By default, protected content is ignored by the Delivery API, and is never exposed through any API endpoints. However, by enabling member authorization in the Delivery API, protected content can be accessed by means of access tokens.
Member authorization in the Delivery API was introduced in version 12.3.
If you are not familiar with members in Umbraco, please read the Members article.
Member authorization
Member authentication and authorization in the Delivery API is performed using the OpenId Connect flow Authorization Code Flow + Proof Key of Code Exchange (PKCE). This is a complex authorization flow, and it is beyond the scope of this article to explain it. Many articles can be found online that explain the flow in detail.
Most programming languages have OpenId Connect client libraries to handle the complexity for us. AppAuth
is a great example of such a library. In ASP.NET Core, OpenId Connect support is built into the framework.
Enabling member authorization
Member authorization is an opt-in feature of the Delivery API. To enable it, configure MemberAuthorization:AuthorizationCodeFlow
in the DeliveryApi
section of appsettings.json
:
Enabled
must betrue
.One or more
LoginRedirectUrls
must be configured. These specify where the server is allowed to redirect the client after a successful authorization.Optionally one or more
LogoutRedirectUrls
must be configured. These specify where the server is allowed to redirect the client after successfully terminating a session.These are only necessary if logout is implemented in the client.
All redirect URLs must be absolute and contain the full path to the expected resource. It is not possible to use wildcards or to allow all paths under a given domain.
When changing the MemberAuthorization
configuration, Umbraco must be restarted to pick up on the changes.
When enabling or disabling member authentication, the DeliveryApiContentIndex
must be rebuilt to correctly reflect the existing content protection state.
The index can be rebuilt from the Examine Management dashboard.
Server endpoints
Many client libraries support automatic discovery of the server OpenId endpoints. This is also supported by the Delivery API, so likely we do not have to worry about the server endpoints.
If automatic discovery is not applicable, the server endpoints must be configured manually. The server endpoints can be found at https://{server-host}/.well-known/openid-configuration
.
Keep in mind that the API versions can change over time, which might affect the configuration.
Client configuration
To connect the client and the server, we need to apply some configuration details to the connection:
The
client_id
must beumbraco-member
.The
response_type
must becode
.The
redirect_uri
must be one of the configuredLoginRedirectUrls
.The
scope
must either be empty, or beopenid
and/oroffline_access
.PKCE must be enabled.
For inspiration, the samples section at the end of this article shows how to configure an ASP.NET Core client.
Logging in members
Authorization Code Flow + Proof Key of Code Exchange (PKCE) requires the authentication service (identity provider) to be separate from the client application. This is to ensure that credentials are never exposed directly to the client application.
As an authentication service, we can use both Umbraco's built-in member authentication and external identity providers. By default the Delivery API attempts to use the built-in member authentication.
How to use the built-in member authentication
First and foremost we need a login page. By ASP.NET Core defaults, this page should be located at /Account/Login
. However, we can change the default path by adding the following piece of code:
To invoke this code, we need to call SetCustomMemberLoginPath()
in Program.cs
:
No matter the path to the login page, we still need a page to render the login screen. Create a content item located at the login page path, and use this template to render it:
With all this in place, it's time to test the setup. Use a browser to perform a request to https://{server-host}/umbraco/delivery/api/v1/security/member/authorize
with these query string parameters:
client_id=umbraco-member
redirect_uri=https://absolute.redirect.url/path/after/login
(replace the value with one of the configured login redirect URLs)response_type=code
code_challenge=WZRHGrsBESr8wYFZ9sx0tPURuZgG2lmzyvWpwXPKz8U
code_challenge_method=S256
If everything works as expected, the request will yield a redirect to the login page. Completing the login form will cause a redirect to the specified redirect URL with a code
query string parameter. The code
can subsequently be exchanged for an access token, which can be used to access protected content.
Do not worry about the URL construction and subsequent handling of the code
parameter. This complexity is what the OpenId Connect client libraries handle for us.
For more inspiration on using the built-in member authentication, check the Members Registration and Login article. Here you will also learn how to create member sign-up functionality.
How to use external identity providers
Umbraco allows adding external identity providers for both backoffice users and members. The process is documented in detail in the External Login Providers article.
The Delivery API supports the same functionality. In the following we'll be using GitHub to test this.
First, we need to create an OAuth App in GitHub. This is done in the GitHub Developer Settings. Use https://{server-host}/umbraco/signin-github
as authorization callback URL in the App.
Once the App is created, generate a new client secret within the App. Make sure to copy both the client ID of your App and the generated secret.
Now we need to connect Umbraco members with the App:
Add the NuGet package
AspNet.Security.OAuth.GitHub
to your Umbraco project.Add the code below to configure the connection to the App. Remember to update the OAuth client ID and secret.
Finally, we need to invoke the connection configuration by calling AddGitHubAuthentication()
in Program.cs
.
There are multiple ways of registering extensions and dependencies like these in your Umbraco project. Which method to use depends on your implementation and preferred way of working.
Learn more about this in the Dependency Injection article.
Now we can test the setup. We'll be calling https://{server-host}/umbraco/delivery/api/v1/security/member/authorize
as described previously, but we need to add one more query string parameter:
identity_provider=UmbracoMembers.GitHub
If the setup is correct, the request will yield a redirect to the GitHub login page. Here we need to authorize the GitHub OAuth App we created earlier, in order to complete the login. Upon completion, a series of redirects will once more take us to the specified redirect URL with a code
query string parameter.
Different client libraries have different ways of declaring the identity_provider
in the authorization request. The samples section shows how to configure this in an ASP.NET Core client.
Combining built-in member authentication and external identity providers
We can also add the external identity providers to the member authentication login screen. This way the end user can decide whether to log in as a registered member, or use an external identity provider.
The Login partial view features an implementation of this combined login experience.
Accessing protected content
When the authorization flow completes we'll obtain an access token. This token can be used as a bearer token to access protected content for the logged-in member:
Access tokens expire after one hour. Once expired, a new access token must be obtained to continue accessing protected content.
Refresh tokens
Refresh tokens provide a means to obtain a new access token without having to go through the authentication flow. A refresh token is issued automatically by the Delivery API when the offline_access
scope is specified in the authorization request.
Refresh tokens are subject to certain limitations and can result in security issues if not applied correctly. All this is beyond the scope of this article to explain in detail. Please familiarize yourself with the inner workings of refresh tokens before applying them in a solution.
Logging out members
The member authorization is tied to the access and refresh tokens obtained in the authorization flow. Discarding these tokens efficiently terminates the access to protected content.
However, the tokens are still valid and can be reapplied until they expire. Depending on your scenario, it might be prudent to revoke the tokens and maybe even terminate the session on the server.
Revoking tokens
Access and refresh tokens can be revoked by performing a POST
request containing the token:
Terminating a session
When terminating a session on the server, the member is logged out of Umbraco. This means any subsequent authorization attempt will require an explicit login.
To terminate the active session for any given member, you must redirect the browser to the signout endpoint. The request must contain one of the white-listed LogoutRedirectUrls
from the appsettings.json
:
Testing with Swagger
The Delivery API Swagger document can be configured to support member authentication.
Before we can do that, we need two things in place:
We have to implement a login page as described above.
We must add
https://{server-host}/umbraco/swagger/oauth2-redirect.html
to the configuredLoginRedirectUrls
.
With these in place, we can enable member authentication in Swagger for the Delivery API by adding the following to Program.cs
:
The Swagger UI will now feature authorization.
Remember to use umbraco-member
as client_id
when authorizing. client_secret
can be omitted, as it is not used by the authorization flow.
Client configuration samples
The following samples show how to configure an ASP.NET Core client to utilize member authorization in the Delivery API.
To put these samples into context, please refer to the article above.
Basic client configuration
Using a named identity provider
Limitations
When using external identity providers, Umbraco still allows for performing local two-factor authentication for members. This feature is not available in the Delivery API. Instead, two-factor authentication should be performed at the identity provider.
Last updated