Build an Angular App Leveraging Sitefinity Headless Capabilities, Part III Featuring Default Authentication

Build an Angular App Leveraging Sitefinity Headless Capabilities, Part III Featuring Default Authentication

Posted on October 13, 2021 0 Comments
SF default Authentication Resource 870x450 RITM0130953

In the third part of our tutorial, learn how to set up the Default authentication for an Angular app that consumes Sitefinity CMS OData services using Sitefinity’s easy-to-use OData SDK.

Note: This is the third post from the series about building an Angular application with Sitefinity’s headless capabilities. You can check part 1 and part 2 here.

In this blog post, we will build on top of the previous Quantum Headless sample and add a new authentication provider to the application. For this purpose, we will also make changes and refactor our previous implementation. But first...

Why are we doing this? Since Sitefinity DX 14.0 introduced a lightweight and easy-to-configure authentication, called "Default". The idea is for it to obsolete SimpleWebToken (SWT and OpenID), which both rely on an internal identity provider shipped with Sitefinity.

More information about the two authentication modes we are using in the app and in Sitefinity: “OpenID” and “Default” can be found here.

Setting up the Authentication in Sitefinity

Let's start implementing our new authentication provider, which will use the “Default” authentication in Sitefinity. For starters, we configure this setup by following the steps below:

1. Navigate to Administration -> Settings -> Advanced -> Security.

2. Under AccessControlAllowOrigin, enter the URL of the development server of the QuantumHeadlessApp (which by default is http://localhost:4200) or *.

3. Navigate to Administration -> Settings -> Advanced -> Authentication -> OAuthServer -> AuthorizedClients.

4. Click Create new. For ClientId enter sitefinity, leave Secret blank.

5. Under RedirectUrls, click the Create new button. Enter http://localhost:4200/auth/oauth/sign-in

NOTE: After modifying the authentication settings, you need to restart Sitefinity. In case you’re working with one of our sandboxes, to restart the site go to Administration -> Modules & services and deactivate the Web Security module.

Implementation

Now we are ready to proceed with the Angular application. Make sure to check out the two previous blogs (Part 1 and Part 2) on using Sitefinity Headless with Angular. In those posts we develop the app, utilize the Sitefinity JavaScript SDK for read and write operations and also add authentication to the app. In this sample, we will extend the code from this repo with a new authentication provider that utilizes the Default authentication in Sitefinity.

Ok, so far, we have used the OidcProvider. Now we want to add another one and use it instead. Let's call in oauth.provider.ts. It implements the AuthProvider interface, like the OidcProvider, and all methods required by it. Since it utilizes the same authentication protocols, we create a settings object with similar properties.

Now let's go over the code of the provider. The setToken method returns the authentication token. The signIn and signOut methods simply redirect to a specific route in Sitefinity responsible for the issuing of the token and its deactivation.

The isLoggedIn method checks if a token is available and whether it is still valid.

You probably figured this out already, but we need a mechanism to distinguish between the two providers and, depending on the settings of Sitefinity, select the proper one. Therefore, we have introduced several additional methods to the AuthProvider interface:

  • getPriority returns a number, signifying the priority in which the provider is chosen. Since from 14.0 the Default authentication is the recommended one, we set a higher priority to the new Oauth provider.
  • The getName method is used only to return a unique string identifier for each provider.
  • isAvailable method deals with checking the availability of each provider in Sitefinity by making a service call to a specific route (different for each provider) and returning a boolean.

How does the authentication service choose the provider?

You will notice that we have changed the getProvider method. What it does now is sort the providers by priority and then it returns to the available provider, starting with the one with higher priority. Then, we initialize the chosen provider.

How does the new provider sign us in Sitefinity?

On sign in, we are redirected to a specific route for authorization. In the URL we specify the return_uri, which is the component on which we want to land after login, as well as the route on which we want to be redirected to - the returnUrl. In our case the return_uri is the oauth-sign-in-redirect component.

After a successful login, we are redirected to this component. In it, we get the segments of the URL, where the value of one of them is the access token. We then call the authentication provider and set the token. After that the user is redirected to the route, specified in returnUrl.

We hope you found this tutorial, as well as our previous two tutorials, useful. We encourage any developer curious about building an Angular app to read all three (ICYMI: links to part 1 and part 2).

If you have any questions, please drop us a line in the comments below. If you're new to Sitefinity, you can learn more here or jump right in and start your free 30-day trial today. We also have the headless topic covered in our free Foundations of Sitefinity Development course, so don’t hesitate to check it out.

Zheyna Peleva headshot

Zheyna Peleva

Jen Peleva was a Principal frontend developer for the Sitefinity CMS.

Comments

Comments are disabled in preview mode.
Topics

Sitefinity Training and Certification Now Available.

Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.

Learn More
Latest Stories
in Your Inbox

Subscribe to get all the news, info and tutorials you need to build better business apps and sites

Loading animation