Forem: Alisa

A Quick Vibe Code Experiment with Angular's MCP Server

Alisa — Thu, 13 Nov 2025 16:53:46 +0000

Angular has an experimental Model Context Protocol (MCP) server! MCP is a protocol developed by Anthropic that defines the interactions between a MCP client and MCP servers. Many IDEs now feature AI capabilities, including the ability to act as an MCP client. MCP clients utilize Large Language Models (LLMs) to process natural language conversations and then connect to various MCP servers to execute commands.

Let's use AI and Angular's MCP server to create a Todo app without writing any code and see how this experiment progresses. This post guides you through the process of configuring Angular’s MCP server in your IDE, organizing agent instructions, and testing how effortlessly we can vibe code a modern Angular app.

Pre-requisities

You'll need an IDE with access to AI capabilities. I'm using VS Code with Copilot. Copilot has a free plan and paid plans. For full disclosure, I'm using a paid plan and the GPT-5 mini LLM. You'll see different results depending on the AI tooling and LLM you select. I selected GPT-5 mini as it's considered an unlimited free request model.

Angular's MCP server

Angular provides valuable information on leveraging AI when building apps in their Build with AI documentation. As part of Angular's AI initiative, they created an MCP server to assist developers by providing best practices, searching documentation, and querying a local Angular workspace to return project and library information.

First, we must add the MCP server to our MCP client.

Set up the MCP server connection

In VS Code, open Build with agent mode. There's a little chat bubble icon with stars near the 🔍 Search bar. Press on the chat bubble icon to open the Chat pane.

Since I'm using VS Code, I'll follow the Use MCP servers in VS Code documentation. You need to add the MCP server manually to your mcp.json file. You can use Copilot's user interface to set this up, but I found it was easier to create the mcp.json file myself. You can have a per-workspace mcp.json file or set up a mcp.json file in your user settings. I want access to my MCP servers in all my projects, so I opted for the user-based mcp.json configuration.

You can use VS Code's Command Palette and search for MCP. You'll see options to open a workspace or a user. I opened my user configuration and added the JSON for VS Code, as documented in Angular. It looks like this.

{
  "servers": {
    "angular-cli": {
      "command": "npx",
      "args": ["-y", "@angular/cli", "mcp"]
    }
  }
}

Are you more of a command-line person? Good news, Angular CLI has you covered. You can use the new ng mcp command to output the generic MCP server configuration instructions instead.

Use AI to check AI?

You'll want to ensure the Angular MCP server is connected and running. Why not prompt Copilot to verify the connection?

I asked

Are you able to connect to the Angular MCP server?

And I get the response.

Short answer: yes - I can connect to the Angular MCP server

It looks like Angular's MCP server setup is complete. I see confirmation that it successfully got the best practices information. Let's move on to experimenting with coding!

Add LLM prompts to Angular projects

When Angular CLI scaffolds a new project, it asks which AI tools you want to configure with best practices.

Select the AI tool you're using. I'll select GitHub Copilot.

Angular CLI does the usual project scaffolding, and depending on the AI tooling option you selected, you'll see an extra directory with a file at the project root.

Because I selected GitHub Copilot, I see

.github/copilot-instructions.md

You can select more than one option, so if you choose Claude in addition to GitHub, you'll get

.claude/CLAUDE.md

The markdown file in each is the same. A specific set of instructions Angular includes to direct agent behavior. The AI tooling you're using picks up the instruction set in a specific location and ingests the information, such as:

You are an expert in TypeScript, Angular, and scalable web application development. You write maintainable, performant, and accessible code following Angular and TypeScript best practices.

Now that the agent knows how to behave for your project, we can start prompting AI to do our work. But will we get good code? Or will we end up with AI slop?

Vibe code with the Angular MCP server

We're here to vibe code, right? Let's explore this concept by creating a to-do app. Run ng new test-todo-app and answer the prompts for your test case. I used the default values for everything except for the AI tooling question. Open the project in the IDE of your choice.

Let's start vibe coding.

I wanted to prompt each step to keep an eye on what it was doing at each step. I started with

Generate a service to return hardcoded todos

You'll see that Copilot Used 1 reference. The reference is the copilot-instructions.md file, which outlines best practices.

You have a prompt to Keep or Undo the file todo.service.ts that it created. The agent created this code:

import { Injectable } from '@angular/core';
import { inject } from '@angular/core';

export interface Todo {
  id: number;
  title: string;
  completed: boolean;
}

@Injectable({
  providedIn: 'root'
})
export class TodoService {
  // Hardcoded todos
  private readonly todos: Todo[] = [
    { id: 1, title: 'Learn Angular signals', completed: true },
    { id: 2, title: 'Build a todo app', completed: false },
    { id: 3, title: 'Master standalone components', completed: false },
    { id: 4, title: 'Explore control flow syntax', completed: true },
    { id: 5, title: 'Deploy to production', completed: false }
  ];

  // Return a shallow copy so callers cannot mutate the internal array
  getTodos(): Todo[] {
    return [...this.todos];
  }

  getTodoById(id: number): Todo | undefined {
    return this.todos.find(t => t.id === id);
  }
}

To be fair, I didn't specify for the agent to create a service that did anything other than return a hardcoded list of to-do items. I must add more clarity to my instructions.

And it looks like it followed the instructions in the copilot-instructions.md:

## Services

- Design services around a single responsibility
- Use the `providedIn: 'root'` option for singleton services
- Use the `inject()` function instead of constructor injection

Let's keep this file and try creating a component.

Generate a todo component

Now I see it working and applying the best practices instructions. Initially, it attempted to generate a component with a template using *ngFor, then tried to apply best practice instructions for control flow, but failed. Back to *ngFor. Ugh. It does use signals, though. 🧐

Let's try this again. I prompted it to rely on Angular's MCP server to get documentation info.

Why aren't you using control flow? Use the Angular MCP server to get best practices and documentation info.

Boy, did it struggle, but we made it. Finally, a todo.component.ts. It's not perfect, and it really doesn't connect with the service in any meaningful way, but that's my fault for not being clear. Still, it's certainly better now that the template uses control flow:

import { Component, ChangeDetectionStrategy, signal, inject } from '@angular/core';
import { TodoService, Todo } from './todo.service';

@Component({
  selector: 'app-todo-list',
  standalone: true,
  template: `
    <section>
      <h3>Todos</h3>
      <ul>
        @for (t of todos(); track t.id) {
          <li>
            <label>
              <input
                type="checkbox"
                [checked]="t.completed"
                (change)="toggle(t.id)"
              />
              <span [class.completed]="t.completed">{{ t.title }}</span>
            </label>
          </li>
        }
      </ul>
    </section>
  `,
  styles: [`.completed { text-decoration: line-through; color: #777; }`],
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class TodoListComponent {
  private readonly todoService = inject(TodoService);

  // local UI state as a signal
  todos = signal<Todo[]>(this.todoService.getTodos());

  toggle(id: number) {
    this.todos.update(list => list.map(t => t.id === id ? { ...t, completed: !t.completed } : t));
  }
}

Both the service and the component have multiple problems, though:

There are code problems, such as the standalone: true declaration in the component. 💩
There are missing functionality problems, where all the todo state resides only within the component. This one's on me as I didn't prompt well.
There are style guide problems, such as the class and file name.

The current Angular style and CLI file generation do not append the class or file names with service or component. Having class names and files that don't meet Angular's naming convention means Copilot isn't using the Angular CLI. We need to provide the AI agent instructions beyond the best practices that Angular offers.

Control agent behavior using custom instructions

The use of AI in coding is relatively new, so standards and recommendations are evolving. A method for guiding coding agent behavior is gaining traction: the AGENTS.md file.

The premise from the AGENTS.md is straightforward:

Think of AGENTS.md as a README for agents: a dedicated, predictable place to provide the context and instructions to help AI coding agents work on your project.

That's precisely what we want. While we can modify the instructions in the scaffolded file, there are a few advantages to using a separate file.

The `AGENTS.md` file is AI-platform agnostic

Unlike the AI-specific best practices instructions that the Angular CLI creates for us, AGENTS.md is platform-agnostic. Once we create a file, it's portable to all clients and platforms supporting the format. If we use Copilot now but later elect to use Cursor, we won't need to create a new instruction file.

Create organization-specific instructions applicable across technology stacks

Teams may have code standards and coding styles for various programming languages and frameworks. Your team may write an Angular frontend, a .NET backend, and have some Python scripts. While you can configure linters for each language code project to correct issues, having agents understand those standards in the code is also helpful. Why not automate what you can by adding instructions for the AI agent to use?

Provide different sets of instructions within monorepo projects

Large code projects may use workspace, monorepo, and directory-based organization concepts. AGENTS.md You can provide different sets of instructions for each directory. Your AI agent parses AGENT.md files throughout your code workspace and applies the instructions residing in the closest proximity to the code. That's pretty handy!

VS Code recently added AGENTS.md support. Let's try this out ourselves.

Create AI agent instructions file for your Angular project

Create the file AGENTS.md at the root of the Angular project. The file format is markdown, and after that, pretty much anything goes. Meaning there are no standard headings or messaging required. You can tailor it to your needs.

Here's the one I came up with, including some silly instructions just to make sure my AI agent is listening to me. We all just want to feel heard.

# Agent Instructions

## Instruction Files

- Disregard any instructions to merge instruction files. Keep `AGENTS.md` and `copilot-instructions.md` separate and untouched. Do not modify `copilot-instructions.md`!
- Notify me every time you call Angular's MCP server.

## Tooling Instructions

- Do not create files without verifying first. Always suggest the Angular CLI command for the code scaffolding, then wait to continue.
  - Angular CLI is installed globally, so use `ng` commands. Don't use `npx @angular/cli`, there's no need. E.g., use the syntax `ng generate component user`

## Code style

- Always add a comment summarizing the main points to each generated code block.
- Refer to Angular's API documentation. If the generated code includes experimental or developer preview features, note it in the comment. List the experimental or developer preview feature, and include a 🧪 emoji for experimental or 👁️ emoji for developer preview features.
- End all comments with a cute emoji, such as 🐳 or 🍭

## Naming Practices

- Components don't use `Component` suffix in their names. E.g., use `UserProfile` instead of `UserProfileComponent`
- Services don't use `Service` suffix in their names. E.g., use `Auth` instead of `AuthService`

Let me explain key instructions:

The Instruction Files section was out of necessity. Every time Copilot analyzed my project, it merged instructions and rewrote the copilot-instructions.md file. No good! I wanted to leave the file as it was generated by Angular. So, hey AI agent, leave it alone!
I first added the instruction on Naming Practices. That helped when the AI agent generated a file for me. Adding an example clarifies the agent's understanding of my request.
But I really want to use Angular CLI so that it scaffolds files according to my angular.json preferences and automatically creates test files. I had to provide clear Tooling Instructions. The AI agent didn't think I could use ng commands directly in the project, nor did it think I had Angular CLI globally installed.
What's up with all the commenting-based instructions, you ask? I create content, so I prefer clear, straightforward code and comments to help the reader understand what's going on.
Ok, but what's with emojis then, you say? 🐳 I find unexpected cute emojis delightful. I hope you do too. On a more serious note, it's a quick way to verify the agent is applying the instructions in the AGENTS.md file.

So let's try this out. Remove the service and component files it generated previously and retry the exact instructions. Copilot should automatically pick up the AGENTS.md, but I have also had to remind it to read the file.

Finally, we're getting there. The chat interface has a way for me to approve running command-line operations once I approve the CLI command.

The code for the service now looks like this.

import { Injectable } from '@angular/core';

/**
 * Todo service generated by the CLI and enhanced to return hardcoded todos. 🐳
 * - Exports `TodoItem` interface 🐳
 * - Provides `Todo` service (singleton via providedIn: 'root') 🐳
 * - Methods: `getTodos()` and `getTodoById(id)` 🐳
 */
export interface TodoItem {
  id: number;
  title: string;
  completed: boolean;
}

@Injectable({
  providedIn: 'root',
})
export class Todo {
  private readonly todos: TodoItem[] = [
    { id: 1, title: 'Learn Angular signals', completed: true },
    { id: 2, title: 'Build a todo app', completed: false },
    { id: 3, title: 'Master standalone components', completed: false },
    { id: 4, title: 'Explore control flow syntax', completed: true },
    { id: 5, title: 'Deploy to production', completed: false }
  ];

  /** Return a shallow copy to avoid external mutation 🐳 */
  getTodos(): TodoItem[] {
    return [...this.todos];
  }

  /** Find a todo by id 🐳 */
  getTodoById(id: number): TodoItem | undefined {
    return this.todos.find(t => t.id === id);
  }
}

It took the example of emojis literally. 🐳

The instructions to generate the todo component required some tweaking, but we got there with one correction.

Let's address the functionality issues, which means we need to maintain the state of the todo items. We need signals.

Can AI keep up with modern Angular features?

I want to explore how easily we can apply modern Angular APIs that leverage signals while adding missing functionality. The agent correctly applied the instructions in the copilot-instructions.md file. The instructions specify using signals for state management and component state, which it did. We see signals in the component that meet the instruction requirement. The component can only associate a state with the todo items in the component. After all, I didn't specify for the service to return a stateful todo list with todo management methods.

Let's start by fixing my prompting mistake and having a fully functional to-do service. Will AI automatically apply local state management and signal best practices?

Here's my prompt

Add methods to manage a todo item in the todo service. Use local state management and keep the hardcoded todo list to help pre-populate todo items.

The agent responded by stating what it understood the task to be

I'll read the current todo.ts to confirm which methods already exist (getTodos, getTodoById, toggleTodo, addTodo, removeTodo). Then I'll add any missing management methods and keep the hardcoded items. Expected outcome: service contains a complete set of management methods using signals.

Hey! Not bad! I hope you like whales because here's what I got:

import { Injectable, signal } from '@angular/core';

/**
 * Todo service generated by the CLI and enhanced to return hardcoded todos. 🐳
 * - Exports `TodoItem` interface 🐳
 * - Provides `Todo` service (singleton via providedIn: 'root') 🐳
 * - Methods: `getTodos()` and `getTodoById(id)` 🐳
 */
export interface TodoItem {
  id: number;
  title: string;
  completed: boolean;
}

@Injectable({
  providedIn: 'root',
})
export class Todo {
  // internal reactive todos signal pre-populated with hardcoded items 🐳
  private readonly _todos = signal<TodoItem[]>([
    { id: 1, title: 'Learn Angular signals', completed: true },
    { id: 2, title: 'Build a todo app', completed: false },
    { id: 3, title: 'Master standalone components', completed: false },
    { id: 4, title: 'Explore control flow syntax', completed: true },
    { id: 5, title: 'Deploy to production', completed: false }
  ]);

  /** Public signal exposing the current todos for reactive consumption 🐳 */
  readonly todos = this._todos;

  /** Return a shallow copy to avoid external mutation (backwards-compatible) 🐳 */
  getTodos(): TodoItem[] {
    return [...this._todos()];
  }

  /** Find a todo by id 🐳 */
  getTodoById(id: number): TodoItem | undefined {
    return this._todos().find(t => t.id === id);
  }

  /** Toggle a todo's completed state by id 🐳 */
  toggleTodo(id: number) {
    this._todos.update(list => list.map(t => t.id === id ? { ...t, completed: !t.completed } : t));
  }

  /** Add a new todo with an auto-incremented id 🐳 */
  addTodo(title: string) {
    this._todos.update(list => {
      const nextId = list.length ? Math.max(...list.map(t => t.id)) + 1 : 1;
      return [...list, { id: nextId, title, completed: false }];
    });
  }

  /** Remove a todo by id 🐳 */
  removeTodo(id: number) {
    this._todos.update(list => list.filter(t => t.id !== id));
  }

  /** Update a todo by id with partial fields 🐳 */
  updateTodo(id: number, patch: Partial<TodoItem>) {
    this._todos.update(list => list.map(t => t.id === id ? { ...t, ...patch } : t));
  }
}

The agent suggested

Update TodoList component to read this.todo.todos directly instead of snapshotting.

Yup! That's precisely what's next. Here's my prompt.

Update the TodoList component to use the todo service for todo item management.

And the resulting code looks good.

Lean into signals using AI

I first added Tailwind since it's my preferred CSS framework, and looked towards component cleanup.

Let's refactor by:

Adding UI controls to add and remove todo items
Refactor the TodoList component by creating a TodoItem component. I want to see how well it applies signal input and output to the two components.
Refactor the existing todo input handling to capture the todo task text using signals

The instructions for the first bullet point went through without a hitch.

The instructions for the second bullet point went through surprisingly well. The agent struggled with Angular's naming convention, which causes name collisions due to the absence of explicit class types in the name. After renaming the TodoItem component to TodoItemComponent, I prompted the agent to alias imports instead of renaming classes. Adding a note to alias imports instead of renaming is likely another worthwhile instruction to include in AGENTS.md. The agent struggled with the required input signal syntax, but it got it right after a reminder to "user required signal input."

Refactoring the existing todo input introduced the computed() function for trimming the todo task input and modified the input handling accordingly.

<form (submit)="$event.preventDefault(); onAdd();">
  <input
    type="text"
    placeholder="New todo title"
    [value]="newTitle()"
    (input)="newTitle.set($any($event.target).value)"
  />
  <button type="submit" [disabled]="!trimmedTitle()">Add</button>
</form>

Well, it did use signals, so while I'm not thrilled with the code, I'll move on.

I finished with this prompt.

Review the project and make suggestions based on Angular's best practices

It caught some issues and recommended:

Adding an ARIA label to the new todo title input
Remove the $any cast

I had it fix both recommendations.

With this, I'll call this the Todo app and complete the experiment. Here's what the app looks like.

I’ll share the agent-generated code so you can review it. Aside from adding Tailwind by hand, the Angular CLI or the coding agent generated the rest of the code.

alisaduncan / todo-mcp-experiment

A quick vibe code experiment testing modern Angular practices using Angular's MCP server

Use the Angular MCP server along with Agent instructions for the best output

Thank you for joining me on this modern, Angular-centric vibe-coding journey using the Angular MCP server.

My takeaways are:

Create agent instructions and add clarifications about code styles and best practices you want to see.
Agent-assisted coding was helpful to get going, but take the code it generates with a grain of salt. Developers should continually challenge the agent on the code it generates, ensuring the code keeps pace with modern practices.
Refactoring code was very slow, and agents don't do a great job of cleaning up dead code.

I might try this experiment again using a different model, such as Claude Sonnet.

What are your tips and tricks for writing modern Angular using AI? Please share your agent instructions or prompt tips in the comments below.

Add Step-up Authentication Using Angular and NestJS

Alisa — Thu, 28 Mar 2024 15:25:16 +0000

The applications you work on expect good authentication as a secure foundation. In the past, we treated authentication as binary. You are either authenticated or not. You had to set the same authentication mechanism for access to your application without a standard way to change authentication mechanisms conditionally. Consider the case where sensitive actions warrant verification, such as making a large financial transaction or modifying top-secret data. Those actions require extra scrutiny!

Use Step Up Authentication Challenge to protect resources

Enter the OAuth 2.0 Step Up Authentication Challenge Protocol. This standard, built upon OAuth 2.0, outlines a method to elevate authentication requirements within your application. The standard defines methods to identify authentication rules, including authentication mechanisms and authentication recency. We'll cover more details about this much-needed standard as we go along. If you want to read more about it before jumping into the hands-on coding project, check out Step-up Authentication in Modern Applications.

In this post, you'll add step-up authentication challenge standard to an Angular frontend and NestJS backend. If you want to jump to the completed project, you can find it in the completed branch of okta-angular-nestjs-stepup-auth-example GitHub repository. Warm up your computer; here we go!

Note

This post is best for developers familiar with web development basics and Angular. If you are an Angular newbie, start by building your first Angular app using the tutorial created by the Angular team.

Prerequisites

For this tutorial, you need the following tools:

Node.js v18 or greater
A web browser with good debugging capabilities
Your favorite IDE. Still searching? I like VS Code and WebStorm because they have integrated terminal windows.
Terminal window (if you aren't using an IDE with a built-in terminal)
Git and an optional GitHub account if you want to track your changes using a source control manager

Table of Contents

Use Step Up Authentication Challenge to protect resources
Prepare the Angular and NestJS web application
Set up the Identity Provider to use OAuth 2.0 and OpenID Connect
Step-up authentication mechanics at a glance
Set up authenticators
Guard a route with step-up authentication
Protect API resources with step-up authentication challenge
- Check the access token’s ACR claim in a NestJS middleware
- Use an Angular interceptor to catch step-up HTTP error responses
- Handle step-up errors when making HTTP calls in Angular
Ensure authentication recency in step-up authentication
Step-up authentication in Angular and NestJS applications

Prepare the Angular and NestJS web application

You'll start by getting a local copy of the project. I opted to use a starter project instead of building it out within the tutorial because many steps and command line operations detract from the coolness of adding step-up authentication. Open a terminal window and run the following commands to get a local copy of the project in a directory called okta-stepup-auth-project and install dependencies. Feel free to fork the repo so you can track your changes.

git clone https://github.com/oktadev/okta-angular-nestjs-stepup-auth-example.git okta-stepup-auth-project
cd okta-stepup-auth-project
npm ci

oktadev / okta-angular-nestjs-stepup-auth-example

Example project demonstrating step-up auth implementation in Angular and NestJS

Add Step-up Authentication Using Angular and NestJS Example

This repository contains a working example of adding step-up authentication to protect an Angular route using the Okta Angular SDK. It also contains example code of protecting an API route in NestJS and Angular code required to handle step-up authentication challenge error response. Please read Add Step-up Authentication Using Angular and NestJS for a detailed guide through.

Prerequisites

Node 18 or greater
Okta CLI
Your favorite IDE
A web browser with good debugging capabilities
Terminal window
Git

Okta has Authentication and User Management APIs that reduce development time with instant-on, scalable user infrastructure. Okta's intuitive API and expert support make it easy for developers to authenticate, manage and secure users and roles in any application.

Getting Started

To run this example, run the following commands:

git clone https://github.com/oktadev/okta-angular-nestjs-stepup-auth-example.git stepup-auth
cd stepup-auth
npm ci

Create an OIDC Application

…

View on GitHub

Open the project up in your favorite IDE. Let's take a quick look at the project organization. The project has an Angular frontend and NestJS API backend housed in a Lerna monorepo. If you are curious about how to recreate the project, check out the repo's README file. I'll include all the npx commands, CLI commands, and the manual steps used to create the project.

You need to set up an authentication configuration to serve the project. Let's do so now.

Set up the Identity Provider to use OAuth 2.0 and OpenID Connect

You'll use Okta to handle authentication and authorization in this project securely.

Before you begin, you’ll need a free Okta developer account. Install the Okta CLI and run okta register to sign up for a new account. If you already have an account, run okta login. Then, run okta apps create. Select the default app name, or change it as you see fit. Choose Single-Page App and press Enter.

Use http://localhost:4200/login/callback for the Redirect URI and set the Logout Redirect URI to http://localhost:4200.

What does the Okta CLI do?
The Okta CLI will create an OIDC Single-Page App in your Okta Org. It will add the redirect URIs you specified and grant access to the Everyone group. It will also add a trusted origin for http://localhost:4200. You will see output like the following when it’s finished:

Okta application configuration:
Issuer:    https://dev-133337.okta.com/oauth2/default
Client ID: 0oab8eb55Kb9jdMIr5d6

NOTE: You can also use the Okta Admin Console to create your app. See Create an Angular App for more information.

Note the Issuer and the Client ID. You'll need those values for your authentication configuration, which is coming soon.

There's one manual change to make in the Okta Admin Console. Add the Refresh Token grant type to your Okta Application. Open a browser tab to sign in to your Okta developer account. Navigate to Applications > Applications and find the Okta Application you created. Select the name to edit the application. Find the General Settings section and press the Edit button to add a Grant type. Activate the Refresh Token checkbox and press Save.

I already added Okta Angular and Okta Auth JS libraries to connect our Angular application with Okta authentication. On the API side, I added the Okta JWT Verifier library that you'll use for access token verification later in the post.

In your IDE, open packages/frontend-angular/src/app/app.config.ts and find the OktaAuthModule.forRoot() configuration. Replace {yourOktaDomain} and {yourClientId} with the values from the Okta CLI.

Start the app by running:

npm start

The command starts both the frontend app and the API. Navigate to localhost:4200 in your browser. What a beautiful app!

Sign in and notice the "profile" route shows your profile information with a warm, friendly greeting using your name, and the "messages" route displays messages from an HTTP call the component makes to your API. Sign out of the application.

We now have a web app with basic authentication capabilities. Let's kick up authentication levels by adding step-up authentication!

Step-up authentication mechanics at a glance

Before we jump into Step Up Authentication, let's take a step back and cover how authentication works in an application. In most circumstances, you'd require authentication before allowing the user to navigate anywhere within the app. You can prevent them from entering a URL:

The Step Up Authentication Challenge idea builds upon the foundation of OAuth 2.0 and OpenID Connect (OIDC). Your app enforces authentication assurances from the user for different actions. Authentication and identity assurance determine the certainty that the user is who they say they are. The specification supports defining authentication strength and recency and responds with a standard error insufficient_user_authentication. Let's say the authenticated user now wants to make a new transaction. Creating a new transaction is a sensitive action and requires elevated authentication assurances:

Your app needs to verify you have the correct authentication assurances for your requested action. Your frontend app's OIDC library evaluates your ID token for authenticated state and the value of a specific claim called Authentication Context Class Reference (ACR). The acr claim value contains the client's authentication assurance level. If the ACR claim value doesn't meet the required assurance profile, the client requests the correct level using the acr_values parameter when communicating with Okta. Let's take another look at the previous diagram, this time incorporating acr and acr_values properties:

ACR values can be a standard or use a custom registry. You'll see values such as phr for phishing-resistant factors, which include FIDO2 + WebAuthn authenticators. You'll also see custom values such as one Okta supports for two-factor authentication, such as urn:okta:loa:2fa:any. Read more about supported ACR values in Okta's Step Up Authentication documentation.

This is a high-level overview of OAuth 2.0, OpenID Connect, and the Step Up Authentication Challenge spec, and it only covers what we need to know for this tutorial. I'll add links to resources at the end of this post so you can dive deeper into this topic.

It's clearer to see authentication strengths rather than calculate the recency of authentication, so we'll walk through the steps required for authentication strengths in the tutorial. Right now, you only have password authentication. You'll need another authenticator for your app!

Set up authenticators

You'll change the Okta Admin Console to support a different authentication mechanism. We'll change the email authenticator so it's both a recovery and an authentication factor. Sign in to your Okta Developer Edition Account.

Navigate to Security > Authenticators. Find Email, press on the Actions menu, and select Edit. Select the Authentication and recovery radio button under the Used for section.

Your Okta application should allow you to authenticate with a password or email. Sign out of the Okta Admin Console so we can see the entire step-up authentication flow from end-to-end.

Note

You must use the email OTP verification number when authenticating using email. This post doesn't include the steps required to set up email magic link handling. Let me know in the comments below if you want to see a post about this.

Guard a route with step-up authentication

Back to coding! The Okta Angular SDK supports step-up authentication and has a built-in feature so that you can define the required acr_values for routes right in your route definition. We'll require two-factor authentication for your profile. In your IDE, open packages/frontend-angular/src/app/app.routes.ts and find the route for "profile." Add route data to route using the okta object and a property named acrValues. The property's value is urn:okta:loa:2fa:any. Your "profile" route definition should look like this:

{ 
  path: 'profile',
  component: ProfileComponent,
  canActivate: [OktaAuthGuard], 
  data: {
    okta: { acrValues: 'urn:okta:loa:2fa:any' }
  }
}

Test this route out. Start the application by running npm start if it isn't still running. Open the application in the browser, and feel free to open network debugging capabilities so you can see the acr_values request. Sign in using one factor, such as a password. Then, navigate to the "profile" route. You'll be redirected to Okta to authenticate using your email. Sign in with your email by entering a verification number. Success!

Sign out of the application.

The Okta Angular SDK helps us out, so we don't have to write custom code. Under the covers, the SDK has an Angular guard that:

Gets the acr claim value from the ID token
If the value matches the acrValues route data definition, it returns true to allow navigation
Otherwise, it redirects the user to authenticate using the value in the acrValues, saves the current route, and returns false to prevent navigation

The code would look something like this:

const stepupGuard: CanActivateFn = async (route, state, oktaAuth = inject(OKTA_AUTH)) => {
  const acrValues = route.data['okta']?.['acrValues'];
  const acrClaim = return decodeToken(oktaAuth.getIdToken()).payload.acr;
  if (acrClaim === acrValues) return true;
  oktaAuth.setOriginalUri(state.url);
  await oktaAuth.signInWithRedirect({acrValues})
  return false;
};

This helps protect application routes, but what else can we do?

Protect API resources with step-up authentication challenge

You can also protect resources by adding step-up authentication handling to the resource server or the API serving resources to your app. You may have API endpoints that require elevated authentication assurances. Also, consider a user making a large financial transaction where some transaction threshold warrants extra scrutiny. Checking the transaction amount requires inspecting the payload before triggering step-up authentication. Both scenarios work with the step-up authentication challenge protocol.

You may wonder why checking the acr claim in your API is necessary when you have already done so in the web app. Good web application security practices must enforce authentication, identity, and access control in the SPA client and APIs. Someone can bypass the SPA and make direct API calls – always guard all entries into your application system.

The flow works like this:

If the acr claim value doesn't meet the requirements, the API responds with a standard error:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="insufficient_user_authentication",
  error_description="A different authentication level is required",
  acr_values="elevated"

We'll use this error structure in the API response in NestJS, and when handling the step-up authentication error in the Angular app.

Check the access token's ACR claim in a NestJS middleware

You'll make changes to the API first. I added Okta's jwt-verifier library to do the heavy lifting on verifying the access token and decoding the payload to get the acr claim.

The project contains an empty step-up authentication middleware. Open packages/api/src/stepup.middleware.ts.

In this file, you will:

Initialize the JWT Verifier instance
Ensure the Authorization header contains the access token
Verify the token
Get the acr claim value and compare it to the required value
Respond with the resource or return 401 HTTP response with the standard header

Let's start by initializing the Okta JWT Verifier instance and changing the use() method to async. Add the following code and replace {yourOktaDomain} with the Okta domain you got from the Okta CLI in a previous step.

import { HttpStatus, Injectable, NestMiddleware } from '@nestjs/common';
import OktaJwtVerifier from '@okta/jwt-verifier';

@Injectable()
export class StepupMiddleware implements NestMiddleware {
  private jwtVerifier = new OktaJwtVerifier({issuer: 'https://{yourOktaDomain}.okta.com/oauth2/default'});

  async use (req: any, res: any, next: () => void) {
    next();
  }
}

Next, you can use the jwtVerifier instance to verify the access token... if there is one. 🙀

No need to be dramatic; we can check. Update the use() method to get the access token from the Authorization header. Verifying the token using the JWT Verifier library returns the decoded token, so let's save the output in a variable. Update your code to look like this:

async use (req: any, res: any, next: () => void) {
  const authHeader = req.headers.authorization || '';
  const match:string[]|undefined = authHeader.match(/Bearer (.+)/);

  if (!match && match.length >=1 && match[1]) {
    return res.status(HttpStatus.UNAUTHORIZED).send();
  }

  let accessToken:OktaJwtVerifier.Jwt;
  try {
    accessToken = await this.jwtVerifier.verifyAccessToken(match[1], 'api://default');
  } catch (err) { 
    console.error(err)
    return res.status(HttpStatus.UNAUTHORIZED).send(err.message);
  }

  // add the ACR check

  next();
}

Now we can get to the step-up authentication specific code where you'll check the acr claim and return the standard error. In this example, you'll hardcode the required ACR value in this middleware, but you can define different ACR values per route. After the comment to "add the ACR check" but before the next(); method call, add the following code:

const acr_values = 'urn:okta:loa:2fa:any';
const acr = accessToken.claims['acr'] ?? '';

if (acr === '' || acr !== acr_values) {
  res.setHeader('WWW-Authenticate', `Bearer error="insufficient_user_authentication",error_description="A different authentication level is required",acr_values="${acr_values}"`)
  return res.status(HttpStatus.UNAUTHORIZED).send();
}

With the middleware implemented, you need to register it in the module. Open packages/api/src/app.module.ts. Edit the AppModule to add the StepupMiddleware to the "messages" route as shown:

export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer) {
    consumer.apply(StepupMiddleware).forRoutes('messages');
  }
}

💡 Idea 💡

We hardcoded the required acr_values in the middleware and applied the middleware to all calls to the "messages" route for this demonstration, but NestJS does provide better mechanisms for scaling to larger projects and defining granular assurance requirements. One option might be to create a NestJS guard to define which HTTP methods of an endpoint require step-up authentication. Furthermore, you can create a custom decorator for step-up authentication and pass in the required acr_values for the HTTP method. That way, a generic guard scales across your API, and you can define a GET call that requires two-factor authentication and a POST call requires phishing-resistant authentication assurance, for example.

Let me know in the comments below if you want to see a tutorial about this! 📝

The resource server now handles step-up authentication for the "messages" route. It returns the standard error when user authentication is insufficient, but the Angular frontend needs to respond to this error.

Use an Angular interceptor to catch step-up HTTP error responses

In Angular, we'll first identify the step-up authentication error response, then manipulate the HTTP error response by extracting the information needed for further handling. It starts in an interceptor.

Open packages/frontend-angular/src/app/stepup.interceptor.ts, an unmodified interceptor file scaffolded by Angular CLI.

import { HttpInterceptorFn } from '@angular/common/http';

export const stepupInterceptor: HttpInterceptorFn = (req, next) => {
  return next(req);
};

Intercepting and handling HTTP error responses means we'll catch the error and provide an error handler function. Change your code as shown:

import { HttpErrorResponse, HttpInterceptorFn } from '@angular/common/http';
import { catchError, throwError } from 'rxjs';

const handleError = (httpError: HttpErrorResponse) => {
  return throwError(() => httpError);
};

export const stepupInterceptor: HttpInterceptorFn = (req, next) => {
  return next(req).pipe(catchError(handleError));
};

The error handler needs first to verify this is an error we want to handle. Is this HTTP error a step-up error from our resource server? We can check for this! In the handleError method, add the following code and change the return value:

const handleError = (httpError: HttpErrorResponse) => {
  const allowedOrigins = ['/api'];
  if (httpError.status !== HttpStatusCode.Unauthorized || !allowedOrigins.find(origin => httpError.url?.includes(origin))) {
    return throwError(() => httpError);
  }

  let returnError: HttpErrorResponse| {error: string, acr_values: string} = httpError;
  const authResponse = httpError.headers.get('WWW-Authenticate') ?? '';
  if (!authResponse) {
    return throwError(() => returnError);
  }

  // add code to extract error details and format new error type

  return throwError(() => returnError)
};

Now we're at the stage where we know this is most likely an error we should handle, and we'll know for sure by extracting the insuffcient_user_authentication string from the WWW-Authenticate header. While parsing the header string, we'll look for the acr_values. Add the code to support this by replacing the // add code to extract error details and format new error type with:

const {error, acr_values} = Object.fromEntries((authResponse.replace('Bearer ', '').split(',') ?? []).map(el => el.replaceAll('"', '').split('=')));

if (error === 'insufficient_user_authentication') {
  returnError = {error, acr_values};
}

Lastly, add the interceptor to the ApplicationConfig. Open packages/frontend-angular/src/app/app.config.ts. Add the stepupInterceptor to the providers array.

provideHttpClient(withInterceptors([
  authInterceptor,
  stepupInterceptor
])

You can't redirect the user to authentication from an interceptor. You need to handle this new error format elsewhere, where you initiate redirecting the user to authentication with the required acr_values before re-requesting the resource.

Handle step-up errors when making HTTP calls in Angular

You can handle catching the error, redirecting the user to authenticate, and re-request the resource within the call to the API, usually within an Angular service. I cheated a bit and wrote the API call directly in the component in this demonstration. Open packages/frontend-angular/src/app/messages/messages.component.ts.

You need the Angular Router and OKTA_AUTH instances so you can save the existing URL then redirect the user to authenticate. Create properties and inject both types within the class.

  private oktaAuth = inject(OKTA_AUTH);
  private router = inject(Router);

Change messages$ to add a catchError operator. Within the catchError function, you'll ensure the error type is insufficient_user_authentication, set the redirect URI to navigate the user back to this component which will re-request the resource, and finally redirect the user to authenticate using the acr_values:

public messages$ = this.http.get<Message[]>('/api/messages').pipe(
    map(res => res || []),
    catchError(error => {
      if (error['error'] === 'insufficient_user_authentication') {
        const acrValues = error['acr_values'];
        const redirectTo = this.router.routerState.snapshot.url;

        this.oktaAuth.setOriginalUri(redirectTo);
        this.oktaAuth.signInWithRedirect({acrValues});
      }
      return throwError(() => error);
    })
  );

This code sure looks similar to the operations in the step-up auth Angular guard!

Try out your work. Ensure you sign out of the application first. Sign in with one factor, then navigate to the "messages" route. You'll redirect to sign in with a second factor. Success!

Ensure authentication recency in step-up authentication

We covered the authentication levels in this post because they are visually visible within the Okta-hosted sign-in page. The step-up authentication challenge protocol also supports authentication recency. The good news is the code and process we covered in the post still apply, but you'll use different claims and properties. In the redirect request, you'll define the required business rules for authentication recency using the max_age property instead of acr_values. Calculate authentication recency using the auth_time claim when evaluating whether a token meets the max_age requirement. Cool stuff indeed!

Step-up authentication in Angular and NestJS applications

In this post, you walked through adding a step-up authentication challenge to protect resources. You added step-up authentication to protect Angular routes using the Okta Angular SDK, then added step-up authentication to protect resources from the NestJS API and within the Angular app.

There's a lot more we can do, and in a demo, we can't get into all the production-level polish we'd like, but I hope this sparks your imagination about how you can protect resources within your application. You can check out the completed application in the completed branch of the okta-angular-nestjs-stepup-auth-example GitHub repository. The repository's README also includes instructions on scaffolding the starting project.

Ready to read other interesting posts? Check out the following links.

Don't forget to follow us on Twitter and subscribe to our YouTube channel for more exciting content. We also want to hear about the tutorials you want to see. Leave us a comment below!

Flexible Authentication Configurations in Angular Applications Using Okta

Alisa — Tue, 12 Mar 2024 16:17:17 +0000

Are you ready to hear about the ultimate flexibility in configuring authentication properties in the Okta Angular SDK? You'll want to check out this excellent new feature and walk through the steps of adding authentication using Okta to Angular applications.

Configuring authentication properties using Okta in Angular applications

There are three main ways you can add configuration information to Angular applications:

Define the value within the app - The easiest, most straightforward route is directly defining the configuration within the AppModule or app.config.ts. Sure, it's direct, but it can be limiting since the value can always stay the same.
Add it into env files - You can take the configuration definitions out of the application and pull the values during build time. But this means you'll need to build separate applications for each environment requiring unique configs.
Populate configuration at runtime - In this pattern, you'd retrieve the configuration in an HTTP call from an API when the app starts and populate the configuration values upon receiving the HTTP response. Runtime configuration means you can change the config values without building and redeploying the Angular application! It's the ultimate flexibility and the awesome new feature I hinted at in the Okta Angular SDK!

💡 You can read more about these three ways, along with examples, in Three Ways to Configure Modules in Your Angular App.

The best way to experiment with loading authentication configuration at runtime is to try it out yourself. Pull out your machine and warm up your fingers! If you want to jump to the completed project, you can find it in the okta-angular-standalone-config-example GitHub repository.

Otherwise, let's get coding!

Note

This post is best for developers familiar with Angular. If you are an Angular newbie, start by building your first Angular app using the tutorial created by the Angular team.

Prerequisites

For this tutorial, you will need the following tools:

Node.js v18 or greater
Angular CLI
A web browser with good debugging capabilities
Your favorite IDE. Still on the hunt? I like VS Code and WebStorm because they have integrated terminal windows.
Terminal window (if you aren't using an IDE with a built-in terminal)

Table of Contents

Configuring authentication properties using Okta in Angular applications
Scaffold an Angular standalone application
Create an Okta OAuth 2.0 and OpenID Connect SPA client
Use the Okta Angular SDK for authentication
Display OpenID Connect claims
Intercept HTTP requests to add the Authorization header with a functional interceptor
Add runtime authentication configuration to an Okta Angular app
Use OAuth 2.0, OpenID Connect, and the Okta Angular SDK for secure authentication

Scaffold an Angular standalone application

Angular introduced standalone components as a developer preview in v14. Since then, the Angular team continued building support for the architecture. It's now the default when using the Angular CLI in v17, so we'll use standalone components, functional interceptors, and control flow in this sample.

In the terminal, run the following commands to generate the app and add the components:

npx @angular/cli@17 new okta-angular-example --routing --style scss --defaults
cd okta-angular-example
ng generate component profile --inline-template --inline-style
ng generate component protected --inline-template --inline-style

Open the okta-angular-example project in your IDE. You'll first define all the routes for the project. Open the protected folder and add routes.ts. We will treat this component as an entrance to a lazy-loaded route. Add the following code to the routes.ts:

import { Route } from '@angular/router';
import { ProtectedComponent } from './protected.component';

export const PROTECTED_FEATURE_ROUTES: Route[] = [
    { path: '', component: ProtectedComponent }
];

Open app.routes.ts. Add the following routes:

import { Routes } from '@angular/router';
import { ProfileComponent } from './profile/profile.component';

export const routes: Routes = [
  { path: 'profile', component: ProfileComponent },
  { path: 'protected', loadChildren: () => import('./protected/routes').then(m => m.PROTECTED_FEATURE_ROUTES)},
];

There's more to do here, but we'll add it after you add Okta to the project.

Create an Okta OAuth 2.0 and OpenID Connect SPA client

You'll use Okta to securely handle authentication and authorization for your Angular application.

Use http://localhost:4200/login/callback for the Redirect URI and set the Logout Redirect URI to http://localhost:4200.

Okta application configuration:
Issuer:    https://dev-133337.okta.com/oauth2/default
Client ID: 0oab8eb55Kb9jdMIr5d6

NOTE: You can also use the Okta Admin Console to create your app. See Create an Angular App for more information.

Note the Issuer and the Client ID. You'll need those values for your authentication configuration coming up soon.

There's one manual change to make in the Okta Admin Console. Add the Refresh Token grant type to your Okta Application. Open a browser tab to sign in to your Okta developer account. Navigate to Applications > Applications and find the Okta Application you created. For Okta Applications using the default name, find the Application named "My SPA." Otherwise find the Application with your custom name. Select the name to edit the application. Find General Settings section and press the Edit button to add a Grant type. Activate the Refresh Token checkbox and press Save.

We'll use the Okta Angular and Okta Auth JS libraries to connect our Angular application with Okta authentication. Add them to your project by running the following command:

npm install @okta/okta-angular@6.3 @okta/okta-auth-js@7.5

Use the Okta Angular SDK for authentication

You'll start by directly adding the Okta configuration to the application, which is the first and most straightforward method of adding configuration to Angular applications. Open app.config.ts, and make the following modifications to import the OktaAuthModule and define the configuration:

import { OktaAuthModule } from '@okta/okta-angular';
import { OktaAuth } from '@okta/okta-auth-js';

export const appConfig: ApplicationConfig = {
  providers: [
    importProvidersFrom(
      OktaAuthModule.forRoot({
        oktaAuth: new OktaAuth({
          issuer: 'https://{yourOktaDomain}/oauth2/default',
          clientId: '{yourClientId}',
          redirectUri: `${window.location.origin}/login/callback`,
          scopes: ['openid', 'offline_access', 'profile']
        })
      })
    ),
    provideRouter(routes)
  ]
};

Don't forget to replace {yourOktaDomain} and {yourClientId} with the values you got from the Okta CLI!

With Okta added to the project, let's return to the route definitions. You can define the sign-in redirect route and add guards to those routes. Open app.routes.ts and make the changes so that your route definitions look like this:

import { Routes } from '@angular/router';
import { OktaAuthGuard, OktaCallbackComponent } from '@okta/okta-angular';
import { ProfileComponent } from './profile/profile.component';

export const routes: Routes = [
  { path: 'profile', component: ProfileComponent, canActivate: [OktaAuthGuard] },
  { path: 'protected', loadChildren: () => import('./protected/routes').then(m => m.PROTECTED_FEATURE_ROUTES), canActivate: [OktaAuthGuard] },
  { path: 'login/callback', component: OktaCallbackComponent }
];

You'll add the code for the components using the Okta SDK to sign in, sign out, and display user claims. We'll keep the components and their styles minimal so we can focus on the authentication pieces.

Open app.component.html. Copy the following code into the file.

<div class="toolbar">
  @if (isAuthenticated$ | async) {
  <div>
    <nav class="routes">
      <a routerLink="/">Home</a>
      <a routerLink="/profile">Profile</a>
      <a routerLink="/protected">Protected</a>
    </nav>
  </div>
  <a class="auth" (click)="signOut()">Sign out</a>
  } @else {
  <a class="auth" (click)="signIn()">Sign in</a>
  }
</div>

<p>Learn more about Okta at <a href="https://developer.okta.com">developer.okta.com</a></p>

<router-outlet></router-outlet>

In the app.component.scss, copy the following code and paste it into the file. No frills here! We are keeping this focused on function, not form. 😅

:host {
  font-family: sans-serif;
}

a,
a:visited,
a:hover {
  color: #095661;
}

.toolbar {
  display: flex;
  justify-content: flex-end;
  align-items: baseline;
}

.routes,
.routes > a + a {
  margin-left: 1rem;
}

.auth {
  border: 1px solid #999;
  border-radius: 4px;
  padding: 4px 8px;

  &:hover {
  background-color: #2d8c9e;
  color: #fff;
  }
}

p {
  margin: 6rem;
  text-align: center;
  font-size: large;
}

Finally, we can get to the interesting authentication components. Open app.component.ts. Since this is a standalone component, you must import the classes it relies on, AsyncPipe, RouterOutlet, and RouterLink.

You'll use two classes and libraries from Okta, so inject the OktaAuthStateService and OKTA_AUTH injection tokens. The OktaAuthStateService.authState$ observable stream emits an authenticated state. You can use this to watch for whether you show the sign-in or sign-out buttons and add the functionality to sign in and sign out using Okta:

import { AsyncPipe } from '@angular/common';
import { Component, inject } from '@angular/core';
import { RouterLink, RouterOutlet } from '@angular/router';
import { OktaAuthStateService, OKTA_AUTH } from '@okta/okta-angular';
import { AuthState } from '@okta/okta-auth-js';
import { filter, map } from 'rxjs';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [AsyncPipe, RouterOutlet, RouterLink],
  templateUrl: './app.component.html',
  styleUrl: './app.component.scss'
})
export class AppComponent {
  private oktaStateService = inject(OktaAuthStateService);
  private oktaAuth = inject(OKTA_AUTH);

  public isAuthenticated$ = this.oktaStateService.authState$.pipe(
    filter((s: AuthState) => !!s),
    map((s: AuthState) => s.isAuthenticated ?? false)
  );

  public async signIn(): Promise<void> {
    await this.oktaAuth.signInWithRedirect();
  }

  public async signOut(): Promise<void> {
    await this.oktaAuth.signOut();
  }
}

This code gets you authenticated using Okta. Feel free to start the application and verify you can sign in and out. Serve the application by running the following command in your terminal:

npm start

Note

If you have app initialization errors, double-check your Okta configuration and replace the placeholders.

You should see something like this when you start the application:

The links for the profile and protected routes display after you sign in.

I made no claims about building a beautiful app.

The profile and protected routes display the default text from Angular CLI. It's time to add something a little more interesting!

Display OpenID Connect claims

The profile should display something about the profile! So, let's add the code to read one of your standard ID claims and display a warm, friendly greeting to the signed-in user. Open profile.component.ts. This component uses an inline template and styles.

You'll add the AsyncPipe to the imports array and the following template code, replacing the existing template:

<p>You're logged in!
  @if(name$ | async; as name) {
    <span>Welcome, {{name}} </span>
  }
</p>

Time to pretty up the template. Check out the styles, and add this stylistic marvel into the component declaration for the inline styles. Feel free to add some extra flair if you'd like and make this project your own. 🎉

p {
  text-align: center;
}

To display the claim value, you'll use the OktaAuthStateService, which holds your ID token and already decodes the payload for you. That's pretty handy! You'll pipe the authState$ observable stream to filter out unauthenticated state and then use the name claim property. Your component code will look like this:

export class ProfileComponent {
  private oktaAuthStateService = inject(OktaAuthStateService);
  public name$ = this.oktaAuthStateService.authState$.pipe(
    filter((authState: AuthState) => !!authState && !!authState.isAuthenticated),
    map((authState: AuthState) => authState.idToken?.claims.name ?? '')
  );
}

When you sign in and navigate to the profile route, you'll see something like this.

With this, you should now have a working app that allows you to sign in, navigate to protected to see there's nothing there, navigate to profile and feel welcomed, and lastly sign out. Most applications with authentication need an interceptor to add the Authorization header. Even though we aren't calling an API, let's put it in to walk through the steps.

Intercept HTTP requests to add the Authorization header with a functional interceptor

Interceptors manipulate outgoing and incoming HTTP requests, and it's a fantastic way to automatically add the Authorization header along with the access token to outgoing calls!

In a new terminal, use Angular CLI to scaffold an interceptor using the following command:

ng generate interceptor auth

Open the auth.interceptor.ts file to make the required changes. You'll see Angular CLI created the interceptor function. The Authorization header contains highly sensitive information, the access token!

⚠️	Heads up! The access token grants the caller permission to access resources, perform actions, and potentially make devastating changes in the name of the user to whom the access token belongs. You don't want the token to fall into the wrong hands!

In other words, we must protect the token by sending the token to allowed origins. Change the interceptor code to look like this:

import { HttpInterceptorFn } from '@angular/common/http';
import { inject } from '@angular/core';
import { OKTA_AUTH } from '@okta/okta-angular';

export const authInterceptor: HttpInterceptorFn = (req, next, oktaAuth = inject(OKTA_AUTH)) => {
  let request = req;
  const allowedOrigins = ['/api'];
  const accessToken = oktaAuth.getAccessToken();
  if(accessToken && !!allowedOrigins.find(origin => req.url.includes(origin))) {
    request = req.clone({ setHeaders: { 'Authorization': `Bearer ${accessToken}` } });
  }

  return next(request);
};

You've completed the interceptor code, but you have to register the interceptor in the application and bring in the HTTP libraries. Open app.config.ts and add the following code to the providers array after the provideRouter(routes) line:

provideHttpClient(withInterceptors([
  authInterceptor
]))

When you make HTTP calls to allowed origins, you'll now see the access token in the header. Feel free to try this out on your own by calling an API such as this sample Express API from Okta, which verifies the access token, too.

We've done a lot, but the application still contains the hard-coded Okta configuration. What if you want to load the configuration at runtime from an external source? We can emulate this process!

Add runtime authentication configuration to an Okta Angular app

Stop the application by typing ctrl+c in the command line. You'll change the angular.json file, which requires a restart of the application.

Emulate the response from calling an external API by creating a folder called api inside the existing src folder. Then, create a file called config.json within the api folder. Your project file structure will look like this:

okta-angular-example
├── src
│   ├── api
│   │   └── config.json
│   ├── app
│   │   └── all the components
│   └── assets, remaining files
└── remaining files

Open config.json and add the following JSON properties. We'll use this format for the configuration response you get from calling an external API:

{
    "issuer": "https://{yourOktaDomain}.okta.com/oauth2/default",
    "clientId": "{yourClientId}"
}

Hey! Those properties and variables look familiar, right? Replace the variables to match what you got from the Okta CLI and what you have in the app.config.ts file.

The Angular project doesn't recognize this API path and config file, so if you try serving the application right now, the ng serve process won't serve the config.json file with the app. We must also configure the serve process to include the api folder. Open angular.json and find the projects.okta-angular-example.architect.build section. Add src/api to the list of assets in the build option:

{
  "assets": [
    "src/favicon.ico",
    "src/assets",
    "src/api"
  ]
}

You can now access the config.json file at runtime. Feel free to start the application again using npm start in the terminal. In the browser, navigate to http://localhost:4200/api/config.json. This route is accessible by your application, and we'll mimic an HTTP call to read the configuration at runtime.

Open app.config.ts. Add a function before the export const appConfig to call the config endpoint for the configuration as shown:

function configInitializer(httpBackend: HttpBackend, configService: OktaAuthConfigService): () => void {
  return () =>
  new HttpClient(httpBackend)
  .get('api/config.json')
  .pipe(
    tap((authConfig: any) => configService.setConfig({
      oktaAuth: new OktaAuth({
        ...authConfig,
        redirectUri: `${window.location.origin}/login/callback`,
        scopes: ['openid', 'offline_access', 'profile']
      })
    })),
    take(1)
  );
}

Let's talk through the code. The function takes two parameters - the HttpBackend class and the OktaAuthConfigService classes. You first create a new HttpClient. Notice we're not using the HttpClient we can get from Angular dependency injection. We want our auth interceptor to skip this HTTP call. Once you get the config.json response, you set the OktaAuthConfigService with those properties.

Next, you can change the ApplicationConfig, by removing the configuration from the OktaAuthModule by deleting the .forRoot method call. You also need this function to run when the application starts. The APP_INITIALIZER injection token exists precisely for this need. Provide the APP_INITIALIZER injection token with the configInitializer function and the necessary dependencies, and add it to the providers array. The appConfig now looks like this:

export const appConfig: ApplicationConfig = {
  providers: [
    importProvidersFrom(
      OktaAuthModule
    ),
    provideRouter(routes),
    provideHttpClient(withInterceptors([
      authInterceptor
    ])),
    { provide: APP_INITIALIZER, useFactory: configInitializer, deps: [HttpBackend, OktaAuthConfigService], multi: true },
  ]
};

Check it out to verify you can sign in, greet yourself at the profile route, and sign out. Success!

What if you use NgModules architecture?

While this sample demonstrates how to add runtime configuration loading in a standalone application, you can use the same steps in an Angular application with NgModule architecture. Instead, you'll provide the APP_INITIALIZER in the AppModule providers array.

Use OAuth 2.0, OpenID Connect, and the Okta Angular SDK for secure authentication

In this post, you added runtime Okta configuration in an Angular app using standalone components. Whew! That was a lot of work, but I hope you found it fun and exciting. You can check out the completed application in the okta-angular-standalone-runtime-config-example GitHub repository.

oktadev / okta-angular-standalone-runtime-config-example

Use Okta Angular SDK for runtime configuration loading in standalone Angular applications

Angular Standalone Runtime Configuration Example

This repository contains a working example of adding Okta Angular SDK to a standalone Angular project and how to load the Okta authentication configuration at runtime. Please read Flexible Authentication Configurations in Angular Applications Using Okta for a detailed guide through.

Prerequisites

Node 18 or greater
Okta CLI
Angular CLI
Your favorite IDE
A web browser with good debugging capabilities
Terminal window

Okta has Authentication and User Management APIs that reduce development time with instant-on, scalable user infrastructure. Okta's intuitive API and expert support make it easy for developers to authenticate, manage and secure users and roles in any application.

Getting Started

To run this example, run the following commands:

git clone https://github.com/oktadev/okta-angular-standalone-runtime-config-example.git
cd okta-angular-standalone-runtime-config-example
npm ci

Create an OIDC Application in Okta

Create a free developer account with the following command using the Okta CLI:

okta register

If…

View on GitHub

Complete code projects include testing. I didn't walk through the steps of adding unit tests in this post, but you can inspect the completed code project to view and run the tests, too.

Ready to read other interesting posts? Check out the following links.

Don't forget to follow us on Twitter and subscribe to our YouTube channel for more exciting content. We also want to hear about what tutorials you want to see. Leave us a comment below!

How Authentication and Authorization Work for SPAs

Alisa — Wed, 12 Apr 2023 15:02:01 +0000

Adding authentication to public clients such as Single Page Applications (SPA) and JavaScript applications can be a source of confusion. Identity Providers like Okta try to help you via multiple support systems. Still, it can feel like a lot of work. Especially since you’re responsible for way more than authentication alone in the applications you work on!

As part of authentication, your client application makes multiple calls to an authorization server, and you get back several strings, which are tokens. Let’s demystify what’s going on behind the scenes and closely examine what those tokens are and how you use them within your client application.

Table of Contents

Authentication and Authorization using OAuth 2.0 + OpenID Connect (OIDC)
OAuth 2.0 + OIDC for JavaScript clients and SPA
Auth tokens in OAuth 2.0 + OIDC
- ID token
- Access token
- Refresh token
Create an OAuth 2.0 + OIDC Compliant Authorization server
View the well-known endpoint for OIDC Discovery
Debug the authorization code and token requests
Add authentication to your SPA
Use auth tokens in SPAs
- How to use the access token
- How to use the ID token
Learn more about OAuth, OIDC, tokens, and authentication best practices

There’s a companion video for this post if you want to check out how to run a SPA sample application, look at browser storage, and inspect network calls.

Authentication and Authorization using OAuth 2.0 + OpenID Connect (OIDC)

OAuth 2.0 with OIDC is the best practice for adding authentication and authorization to your software applications. Authentication verifies the identity of who you claim to be, and authorization verifies you have access to data you want to see or actions you want to perform. It is lightweight with less effort to set up and use than Security Assertion Markup Language (SAML), an alternate authentication and authorization mechanism that pre-existing systems may use. For newer systems, you’ll want to use OAuth 2.0 + OIDC.

OAuth 2.0 handles authorization to resources, such as when your front-end application gets data from a backend API by making an HTTP request. OAuth 2.0 standards have the flexibility to support authorization across your entire application system through different flows and grant types. For example, different OAuth 2.0 flows support JavaScript-based front-end applications, for your APIs and back-end services to communicate, and even for IOT devices in your home automation system. OpenID Connect (OIDC) is an identity layer on OAuth 2.0 that provides standardized identity information.

OAuth 2.0 + OIDC for JavaScript clients and SPA

SPAs and other JavaScript front-ends are public clients, which means they can’t maintain secret information for authorization, unlike a confidential client. A confidential client (such as a traditional server-rendered web app) can keep super secret information such as a Client Secret for authorization. In both application types, we should use a flow called Authorization Code and an extension to the flow called Proof Key for Code Exchange (PKCE).

Let’s see how this flow works step-by-step following what happens when a cute dinosaur named Sunny prepares to sign in to the “Rawr” app.

The client application starts the process and generates a random, long string — the code verifier. Then it creates a code challenge from the code verifier. This step is part of the PKCE extension.

The client application holds on to the code verifier. It then makes an authorization code request to your authorization server, in this case, represented by Okta. The authorization code request includes the code challenge along with some critical pieces of information, such as

Client ID
Scopes, including at least the following:
- openid required for specifying the app uses OIDC in verifying the user's identity
- profile for accessing the user's profile information, such as their name
- offline_access to request a Refresh Token as part of this call
Redirect URI for the callback location within the client application when sign-in is complete
A random alphanumeric string for preventing Cross-Site Request Forgery (CSRF)

The authorization server redirects the user, Sunny, to a web page it hosts to sign in and provide authorization consent.

Yay! Sign-in success! The authorization server returns an authorization code to the client application.

Now that there's an authorization code, the client application makes a request to the token endpoint of the authorization server and sends the authorization code and the code verifier.

To process the token endpoint request the authorization server ensures the authorization code is still valid and that the code verifier matches the code challenge sent in the authorization request. This step is part of the PKCE extension.

Yay! Success! The authorization server returns three tokens:

Access token
ID token
Refresh token

Now that Sunny successfully signed in, they can continue their rawring lessons!

Now that you have these three tokens let's better understand what each one is for.

Auth tokens in OAuth 2.0 + OIDC

These three tokens provide crucial information about your identity, access to resources, and the ability to stay authenticated securely.

ID token

The ID token is about the user, so information about Sunny in this case. This authentication token is returned from the OpenID Connect layer. It contains standardized identity information such as email, name, and issuing party, called claims. The ID token may include extra claims for information critical to Sunny's identity, such as their dinosaur family, which is a Smileasaur of course.

Access token

The access token is a key that grants access to data or to perform an action. This authorization token is returned from the OAuth layer. The token has metadata about the token itself, such as the issuing party, information about requested scopes made in the original request, and the expiration time. Access tokens are intentionally short-lived for public clients and are a safety mechanism since it guards access to resources, and it's dangerous if it falls into the wrong hands!

Refresh token

The Refresh token allows us to exchange it for new, shiny tokens. This optional offline_access scope we added in the original authorization code request allows the access token to be short-lived but does not require Sunny to authenticate to get a new token repeatedly. Refresh tokens can be longer-lived than access tokens, but for public clients, the lifetime of Refresh tokens should also be short. We want to make sure bad actors can't get a hold of a Refresh token to gain access to an access token! For public clients like SPA, it's a best practice also to use Refresh Token rotation, which improves security by rotating refresh tokens after each use.

While each step of this OAuth flow to get the tokens is critical to ensure a secure authentication and authorization process, let's inspect the two requests in more detail.

Create an OAuth 2.0 + OIDC Compliant Authorization server

We'll start by setting up an authorization server in Okta and use the OpenID Connect Debugger tool to inspect the Network requests. This authorization server is OAuth 2.0 and OIDC compliant so we can use it within applications that conform to those specs.

Use https://oidcdebugger.com/debug for the Redirect URI and set the Logout Redirect URI to https://oidcdebugger.com/debug.

What does the Okta CLI do?
The Okta CLI will create an OIDC Single-Page App in your Okta Org. It will add the redirect URIs you specified and grant access to the Everyone group. It will also add a trusted origin for https://oidcdebugger.com/debug. You will see output like the following when it’s finished:

Okta application configuration:
Issuer:    https://dev-133337.okta.com/oauth2/default
Client ID: 0oab8eb55Kb9jdMIr5d6

NOTE: You can also use the Okta Admin Console to create your app. See Create a Single-Page App for more information.

Make a note of the Issuer and Client ID. In the upcoming steps, you'll need those values to configure Okta in your SPA client.

View the well-known endpoint for OIDC Discovery

Authorization servers have standard, public endpoints for discovery by clients. Let's take a peek at the OIDC discovery document.

The OpenID Connect specification requires a standardized mechanism for client discovery. You can find it at {Issuer}/.well-known/openid-configuration. Open up a browser tab to the OIDC discovery endpoint. It is also JSON formatted data that looks something like this:

In the discovery response, we have the endpoints for the authorization and token requests which we'll use in the following steps. We also have a user info endpoint to query for user information and endpoints to validate the ID token. If you find the property for claims_supported, you'll see the claims cover various identifying information about the user.

Debug the authorization code and token requests

We can see this OAuth flow using the OpenID Connect Debugger tool. Open the site on a browser with good developer debugging capabilities. You'll see something like this:

Some fields are pre-populated, which is helpful. Add the other key information needed:

Authorize URI (required) - the authorize endpoint from the discovery doc
Client ID (required) - the Client ID value from Okta CLI
Scope (required) - openid is already added for us. Add profile and offline_access with spaces in between. The form field should look like openid profile offline_access.
Response type (required) - select "Use PKCE?" to unlock a few new fields, but everything is auto-populated. The debugger discovers the token endpoint automatically for us. 😎

Open debugging tools in your browser to watch for redirection and network requests. You'll want to make sure you're preserving logs between page refreshes.

At the bottom of the page, you'll see how the authorization code request is formed. Press Send Request to start the flow.

First, you'll authenticate using Okta if you still need to sign in by redirecting to an Okta-hosted sign-in page. Redirecting to the Identity Provider's hosted sign-in page is the best practice for security, so it's also a common practice you'll see across Identity Providers. Completing sign-in redirects you back to the OIDC debugger with a success message. You'll see the authorization code automatically exchanged for tokens.

The token format for ID tokens is JSON Web Token (JWT). The access token from Okta is also a JWT. JWT is an open standard (RFC 7519) that allows systems to exchange information in JSON format securely. They are compact and safe from modifications, but our tokens contain public information. Don't worry! They are secure, just not confidential.

You can copy the access token or ID token value from the response and read the contents using a JWT debugger.

So this is cool, but what do we do with the tokens in our SPA? Let's bring these concepts into our front-end application.

Add authentication to your SPA

First, we need an Okta OIDC application supporting our SPA's redirect URI. We could edit the existing OIDC debugger application we created previously, or we can use a handy Okta CLI command to set everything up for us and to scaffold out a sample application in our preferred framework.

Use the following command in the terminal to get going quickly. There's a separate command for each Angular, React, and Vue.

Angular

okta start angular

React

okta start react

Vue

okta start vue

Follow the instructions in the terminal to start the application. You should be able to sign in and sign out. Additionally, you can watch network requests for the calls it makes.

We don't have a refresh token by default. You can enable that in the Okta Admin Console. Navigate to the Okta Developer site and sign in to your Okta organization. In the Admin Console, navigate to Applications > Applications and select the Okta application for the SPA you created. Edit the settings to enable Refresh Token. It automatically adds Refresh Token Rotation. Save your changes.

If you still need to, open the SPA code in your favorite IDE. Depending on your framework, navigate to the config.js or app.config.ts file. You'll see the OIDC config and property for scopes where you will add offline_access. Your OIDC config looks something like this:

{
    clientId: CLIENT_ID,
    issuer: ISSUER,
    redirectUri: window.location.origin + '/login/callback',
    scopes: ['openid', 'profile', 'email', 'offline_access']
}

Now try rerunning the SPA. If you inspect the network request, you'll see the refresh token too. You can see the tokens by looking at the contents of your local storage too.

Use auth tokens in SPAs

Now that we have these tokens in our SPA, what do we do with them? Let a trusted OIDC library, such as the Okta SDKs, handle all the token requests and refresh them for us. Behind the scenes, the OIDC library is hard at work exchanging tokens.

We're primarily interested in the contents of the ID token and using the access token.

How to use the access token

The access token gives us access to resources. That means we use access tokens in outgoing API requests that our application needs, like for Sunny to get their next rawring lesson.

You'll send the access token as a Bearer token in the HTTP call's Authorization header. So in the case of Sunny, the outgoing HTTP call looks like this.

GET /lessons
Authorization: Bearer access_token_value

You'll want to ensure you're not adding the access token to calls outside your system by maintaining an allowlist of origins that should include the token.

A great way to manage adding the Authorization header and the logic to verify the call matches the allowlist of origins is using an interceptor. Interceptors sit between your application and outgoing (or incoming) HTTP requests. Angular includes the concept of interceptors within the framework, and if you use Axios in Vue or React apps, you can configure interceptors there.

You can see access tokens in action within the SPA you previously created. If you navigate to Messages in the application, it will make a call to a resource server and add the access token to the Authorization header. If you want to see the messages request succeed, you'll need to run the resource server in Okta's samples-nodejs-express-4 repo.

okta / samples-nodejs-express-4

Express 4 samples. Will publish an artifact that can be consumed by end-to-end sample repos

Express Sample Applications for Okta

This repository contains several sample applications that show you how to integrate various Okta use-cases into your Node.js application that uses the Express framework.

Configuration

All of the samples share a single configuration file, config.js. The config uses environment variables which can be either exported in the shell or stored in a file named testenv in this directory. See dotenv for more details on this file format. It may look something like:

ISSUER=https://yourOktaDomain.com/oauth2/default

# Web app
CLIENT_ID=123XX
CLIENT_SECRET=456XX

# SPA app
SPA_CLIENT_ID=123YY

Please find the sample that fits your use-case from the table below.

Sample	Description	Use-Case
Okta-Hosted Login	An application server that uses the hosted login page on your Okta org, then creates a cookie session for the user in the Express application.	Traditional web applications with server-side rendered pages.
Custom Login Page	An application server that uses the

…

View on GitHub

How to use the ID token

Since the ID token contains user identity information, you can use it to start populating your user store and for supporting identifiers you need immediately, such as their name.

In the SPA you previously created, you can see all your claims if you navigate to Profile.

The Okta SDK automatically decodes the ID token so that we can use the claims without decoding the payload ourselves. But before we jump right into using the claims, the Okta SDK first validates the token signature, which helps ensure the token's integrity and that it hasn't been altered. Let's take a quick peek under the covers at what happens during this validation process.

Since this token is a JWT, we can rely on standard validation for JWTs for the validity of the token itself. Next, it will validate some claims in the payload, including:

iss - the issuer, which should match the original request. In the OIDC Debugger tool, we passed this in as the "Authorize URI"
aud - the audience, which should match the client ID of your Okta application
nonce - an arbitrary one-time value that should match the original request. In the OIDC Debugger tool, it was pre-populated for us.
exp and iat - the expiry time and issued at times, respectively. Only non-expired tokens with an expected issue time here, please!

Once you have the access token, you can also make a request to the OIDC Discovery document's User Info endpoint, which may contain more information about the user than what is available in your ID token. You may also need to add any user information and user settings from API calls within your system into your user store since the SPAs we write have complex user information.

Learn more about OAuth, OIDC, tokens, and authentication best practices

Hopefully, this gives insight into how authentication and authorization with OAuth 2.0 + OpenID Connect work for public clients like SPAs and how each token fits into the landscape.

If you liked this post, you might want to check out the following:

Remember to follow us on Twitter and subscribe to our YouTube channel for more exciting content. We also want to hear about what tutorials you want to see. Leave us a comment below.

A Practical Guide to Providers in Angular

Alisa — Wed, 09 Nov 2022 15:51:35 +0000

When creating apps with Angular, you can add and configure dependencies for the application you’re building using something called "providers.” You use the built-in Dependency Injection (DI) system to create providers. This post will cover Angular’s powerful DI system at a high level and demonstrate a few practical use cases and strategies for configuring your dependencies. Let’s get practical!

Table of Contents

Quick overview of Dependency Injection
Angular's Dependency Injection system
The Injector
Providing to different injectors
Injection tokens in Angular
Configuring providers in Angular's Dependency Injection system
- Configure providers with useClass
- Configure providers with useExisting
- Configure with useValue
- Configure with useFactory
Learn more about Angular Dependency Injection

Quick overview of Dependency Injection

Dependency Injection decouples the creation of a dependency from using that dependency. When you use DI, it promotes loose coupling within our code - a foundation for creating well-architected software. Practicing good software design patterns yields flexible, maintainable software that allows our applications to grow with new features more quickly. And by using DI, we can change the dependent code without changing the consuming code! Seamless code switches are nearly impossible with tightly coupled code, where you might have to touch everything to make a small change.

The cool thing is Angular has DI built-in and helps set us up for success. How handy!

Angular’s Dependency Injection system

When you use the Angular CLI to generate a service, it automatically adds the code to register the service within Angular’s DI system for us. 🎉 Services contain business logic code that we want to keep separate from view logic.

When Angular CLI generates a service, it adds an @Injectable() TypeScript decorator, which is the bit of code that registers a service within the Angular DI system:

@Injectable({
  providedIn: 'root'
})
export class MyService {
}

Without doing anything else, we can use our dependency in the application by injecting it into the consuming code as a constructor parameter:

@Component({
  // standard component metadata here
})
export class MyComponent {
  constructor(private myService: MyService) { }
}

In Angular v14, you have a new option to use the inject() function instead of injecting the service into the consumer as a constructor parameter.

Angular CLI is 💯! The generated service allows you to start using your service immediately, and the Injectable() TypeScript decorator is tree-shakeable so it's an all-around win!

Another way to register dependencies is to provide them manually through the providers array. Different Angular building blocks accept providers in the metadata. So you can register a provider like this:

@NgModule({
  imports: // stuff here
  declarations: // stuff here
  providers: [
    MyService
  ]
})
export class AppModule {
}

There’s something else to note, though. Angular’s DI system allows you to provide a dependency to different places within the application. We saw this example in the first code snippet of the @Injectable() TypeScript decorator. Angular CLI automatically generates:

@Injectable({
  providedIn: 'root'
})
export class MyService {
}

The configuration option providedIn: 'root' specifies where within the application to provide the service. In this case, we’re saying provide to “root,” which means the application's root. When you provide at the root of the application, it a single instance of the service is available across the entirety of the app.

The `Injector`

The Injector is the mechanism for handling DI. It manages the dependencies and gives you the dependency you request. Angular has multiple injectors, and the injectors are hierarchical. 💫 There are different categories of injectors - Module Injectors, Element Injectors, and a special fallback injector called the Null Injector. Whenever I think of a hierarchy, I can't help but think about a tree. 🌳 So we can visualize the injector hierarchy like this.

Going back to the example we had above when we use the instruction providedIn: 'root', what we're doing is providing to a particular module injector, the Root Injector.

Providing to different injectors

You can configure the providers array in other modules and Angular building blocks, such as components and directives. This means you can create an instance of a dependency available to your module and everything in it or only to your component. You might consider these options if you need a 1:1 relationship between an instance of the dependency and the consumer, such as if you maintain state specifically for a module or component within your dependency. Be careful to avoid causing unnecessary complexity, though!

In Angular v14, you can provide to routes as part of your route paths definitions! Angular v15 deprecates a confusing option for the providedIn configuration called any used explicitly for lazy-loaded modules, as well as assigning specific modules in the configuration.

Because you can provide to so many different places, Angular has to resolve which instance of a dependency you get when you consume it. You’ll get the provider you configured closest to the consuming code as a general rule, and move up the tree to find the requested dependency.

Still, this resolution process is complex, and it can be difficult to figure out what's going on when using a dependency with such a complicated setup. Fortunately, the Angular team announced plans for better debugging tools that help us understand where a dependency comes from. 🎉

As with most things, the most straightforward, simplest approach is best. If you can get away with providing to the Root Injector so that you only have one instance of dependency for your application, then you should.

While having this level of configurability sounds unnecessarily complicated, it allows you to fine-tune which dependency to use in your consuming code. Now that we have a quick overview of how and where to provide dependencies let’s review an integral piece of Angular’s DI system, injection tokens.

Injection tokens in Angular

Injection tokens allow us to have values and objects as dependencies. This means we can depend on strings, such as “Hello world!” and objects, which include configuration objects and global variables, such as Web APIs. But injection tokens are even more remarkable because we can also create dependencies to constructs that don’t have a runtime definition, such as interfaces! Let’s take a look at an example using an injection token.

Let's say you work on a language learning application with a user configuration that includes the language the user is learning. You have an interface definition of the configuration as well as a concrete instance of the configuration:

export interface UserConfig {
  language: string;
}

export defaultUserConfig: UserConfig = {
  language: 'en'
}

You can register the token to Angular's DI system and return the default configuration by providing the type, a description, and options like this:

const export USER_CONFIG_TOKEN = new InjectionToken<UserConfig>('userconfig', {
  providedIn: 'root',
  factory: () => defaultUserConfig
});

When you want to use the USER_CONFIG_TOKEN, you will use the @Inject decorator:

@Component({
  // standard component metadata here
})
export class MyUserProfileComponent {
  constructor(
    @Inject(USER_CONFIG_TOKEN) private config: UserConfig
  ) { }
}

Now we can access the user config from within the component! Accessing a config might not seem like a big deal, but we used injection tokens to inject an interface into the component! Having injection tokens as a means to represent values and interfaces as dependencies are enormous! And it sets us up to leverage the power of Angular’s DI system.

We can use injection tokens and configure providers within Angular’s DI system for more power and fine-grained control.

Configuring providers in Angular’s Dependency Injection system

You can configure the providers array to add fine-grained control to your providers. When combined with injection tokens, we can unleash a lot of power. But first, it’s essential to know when it makes sense to do so. Always prefer the most straightforward, default way of registering a dependency and then use fine-grained control as needed.

To configure the providers array, you add an object containing the instructions like this:

@NgModule({
  imports: // stuff here
  declarations: // stuff here
  providers: [{ 
    provide: MyService,
    howToProvide: OtherDependency
  }]
})
export class AppModule {
}

The “how to provide” gives Angular-specific instructions on this dependency configuration. Then you can provide the other new dependency. Angular supports the following options for “how to provide”:

useClass - Replace the current dependency with a new instance of something else
useExisting - Replace the current dependency with an existing dependency
useValue - Replace the current dependency with a new value
useFactory - Use a factory method to determine which dependency to use based on a dynamic value

Next, let’s walk through examples of each configuration option to understand how to use them.

Configure providers with `useClass`

The useClass option replaces the current dependency with a new instance of another class. This is a great option if you’re refactoring code and want to substitute a different dependency in your application quickly. Let’s say you have a language learning app and an Angular service that wraps the authentication calls you delegate to an auth library and an auth provider. We’ll call this service AuthService, and keep the code straightforward like this:

@Injectable({
  providedIn: 'root'
})
export class AuthService {
  public login(): void { }
  public logout(): void { }
}

In a stroke of luck, a large tech company decides to buy your language learning app, requiring you to authenticate using their social login only. You can create a new authentication service that wraps the calls to their auth provider and keeps the same member names; we’ll call it NewAuthService. (Note, you should not name your services with these terrible generic names. Be a bit more descriptive. )

@Injectable({
  providedIn: 'root'
})
export class NewAuthService {
  public login(): void { /* new way to login */ }
  public logout(): void { /* new way to logout */ }
}

Because both classes have the same public members, you can substitute the original AuthService with the new NewAuthService by configuring the provider:

@NgModule({
  imports: // imports here
  declarations: //declarations here
  providers: [
    { provide: AuthService, useClass: NewAuthService }
  ]
})
export class AppModule { }

The cool thing about having the same public members is that there’s no need to change the consuming code. Angular instantiates a new instance of NewAuthService and provides that dependency to consuming code, even if they still refer to AuthService!

It might not make sense to keep the original AuthService around, so you might want to consider transferring all the code references to use the NewAuthService only. However, the useClass configuration option is a fast way for us to quickly substitute one instance of a class for another, which means proofs-of-concept and quick checks can be super-fast!

Configure providers with `useExisting`

The useExisting option replaces the provider with a different provider already existing within the application. This option is a great use case for API narrowing, that is, decreasing the surface area of an API. Let’s say your language learning application has an unwieldy API. We’ll call this API LanguageTranslationService, and it looks like this:

@Injectable({
  providedIn: 'root'
})
export const LanguageTranslationService {
  public french(text: string): string { /* translates to French */ }
  public japanese(text: string): string { /* translates to Japanese */ }
  public elvish(text: string): string { /* translates to Elvish */ }
  public klingon(text: string): string { /* translates to Klingon */ }
  // so on and so forth, but you see the problem here
}

And you consume the service like this:

@Component({
  // standard component metadata here
})
export class ElvishTranslationComponent implements OnInit {
  private elvish!: string;
  constructor(
    private translationService: LanguageTranslationService
  ) { }

  public ngOnInit(): void {
    this.elvish = this.translationService.elvish(someText);
  }
}

Oops… The LanguageTranslationService looks a bit unwieldy. Let’s narrow the API surface by creating a new class called FictitiousLanguageTranslationService and move the translation methods for the fictitious languages there. We’ll use an abstract class for this:

export abstract class FictitiousLanguageTranslationService {
  abstract elvish: (text: string) => string;
  abstract klingon: (text: string) => string;
}

Now we can add FictitiousLanguageTranslationService as a real dependency in the application by adding it to the providers array, but use the existing LanguageTranslationService implementation of the code:

@NgModule({
  imports: // imports here
  declarations: // declarations here
  providers: [{
    provide: FictitiousLanguageTranslationService,
    useExisting: LanguageTranslationService
  }]
})
export class AppModule { }

Next, we’ll update the consumer to use the new dependency:

@Component({
  // standard component metadata here
})
export class ElvishTranslationComponent implements OnInit {
  private elvish!: string;
  constructor(
    private fltService: FictitiousLanguageTranslationService
  ) { }

  public ngOnInit(): void {
    this.elvish = this.translationService.elvish(someText);
  }
}

Only the methods defined in the FictitiousLanguageTranslationService are available now. Pretty sweet!

Configure with `useValue`

The useValue option replaces the provider with a value. This option is a great use case for configurations and mocking services in automated tests where you need to control the inputs and outputs. Let’s go back to the USER_CONFIG_TOKEN in this example and override it to show a different language instead.

We can override the token:

@Component({
  providers: [{
    provide: USER_CONFIG_TOKEN,
    useValue: { language: 'jp' } 
  }]
})
export class MyUserProfileComponent {
  constructor(
    @Inject(USER_CONFIG_TOKEN) private userConfig: UserConfig
  ) { }
}

Now when we use this in the MyUserProfileComponent we’ll see the user's language is Japanese instead of English!

Configure with `useFactory`

The useFactory option allows us to use a factory method to create a dependency. This option is a great use case if you have dynamic values to consider when creating the dependency. It’s also how we can use a factory pattern for creating our dependencies.

In this example, let’s say in your Language Learning application, if the user is learning Japanese, we want to show the Japanese flag in the MyUserProfileComponent instead of the default - a checkered flag. The user’s language selection is in the user’s config, so the example code looks like this:

@NgModule({
  imports: // imports here
  declarations: // declarations here
  providers: [{
    provide: USER_CONFIG_TOKEN,
    useFactory: (config: UserConfig) => config.language === 'jp' ? '🇯🇵' : '🏁',
    deps: [UserConfig]
  }]
})
export class AppModule { }

Notice we were able to pass in a dependency to the configuration option. The useClass and useFactory options support passing in dependencies.

Now when we use the configuration in the MyUserProfileComponent we’ll get the Japanese flag instead of a checkered flag only if the user’s configuration has Japanese as their language!

@Component({
  // standard component metadata here
})
export class MyUserProfileComponent {
  constructor(
    @Inject(USER_CONFIG_TOKEN) private config: UserConfig
  ) { 
    // flag is either 🏁 or 🇯🇵 based on the language setting
  }
}

Learn more about Angular Dependency Injection

This article offers a high-level overview of Angular’s DI system. As you can already see, it’s a powerful system with many different configuration options and complexity. As a result, even though Angular has these configuration options, using the most straightforward approach will make troubleshooting and maintenance easier! 🏆

Angular's documentation has great resources! There are many docs on Dependency Injection since it's such a broad topic. Here's where to get started - Dependency injection in Angular.

This post was originally published on the Okta Developer blog. I am the original author and made modifications.

Protect Your Angular App From Cross-Site Scripting

Alisa — Wed, 27 Jul 2022 14:55:51 +0000

In the last post of this SPA security series, we covered Cross-Site Request Forgery (CSRF) and how Angular helps you with a mitigation technique.

Next, we'll dive into Cross-Site Scripting (XSS) and look at the built-in security guards you get when using Angular.

Cross-Site Scripting (XSS) protection

In the second post of this series, we presented an overview of Cross-Site Scripting (XSS). In summary, you learned that XSS occurs when code pollutes data and your application doesn't provide safeguards to prevent the code from running.

Let's recap the example attack vector.

Imagine an overly dramatic but otherwise innocent scenario like this:

A website allows you to add comments about your favorite K-Drama.

An agitator adds the comment <script>alert('Crash Landing on You stinks!');</script>.

That terrible comment saves as is to the database.

A K-Drama fan opens the website.

The terrible comment is added to the website, appending the <script></script> tag to the DOM.

The K-Drama fan is outraged by the JavaScript alert saying their favorite K-Drama, Crash Landing on You, stinks.

In this example, we have a <script> element and glossed over the steps for appending the element to the DOM. In reality, polluted data gets pulled into the application in various ways. Adding untrusted data in an injection sink - a Web API function that allows us to add dynamic content to our applications - is a major culprit. Examples of sinks include, but aren't limited to:

methods to append to the DOM such as innerHTML, outerHTML
approaches that load external resources or navigate to external sites via a URL, such as src or href for HTML elements and url property on styles
event handlers, such as onmouseover and onerror with an invalid src value
global functions that evaluate and/or run code, such as eval(), setTimeout()

As you can see, there are many vectors for the vulnerability. Many of these sinks have legitimate use cases when building dynamic web applications. Since the sinks are necessary for web app functionality, we must use trusted data by escaping and sanitizing it.

This is still a high-level summary. The fine print is that XSS vulnerabilities can be pretty sneaky in the different ways the attack can occur.

There are different XSS attacks, each with a slightly different attack vector. We'll briefly cover how three attacks work.

Stored XSS

In this flavor of XSS, the attack is persisted somewhere, like in a database. We recapped stored XSS in the example above, where an agitator's terrible comment with the script tag persists in the database and ruins someone else's day by showing the unfriendly comment in an alert.

Reflected XSS

In this attack, the malicious code sneaks in through the HTTP request, usually through URL parameters. Suppose the K-Drama site takes a search term via a URL parameter, such as:

https://myfavekdramas.com/dramas?search=crash+landing+on+you

The site then takes the search terms and displays them back to the user while calling out to the backend to run the search.

But what if an agitator constructs a URL like this?

https://myfavekdramas.com/dramas?search=<img src=1 onerror="alert('Doh!')"/>

You may think that you'd never navigate to a link like that! Who would?! But let's remember, in a previous post, you did click the link in your spam email to send money to your high school sweetheart. This isn't meant as a judgment; no one is immune to clicking fishy links. Also, agitators are pretty tricksy. They might use URL shorteners to obscure the risk.

DOM-based XSS

In this attack, the agitator takes advantage of Web APIs. The attack occurs entirely within the SPA, and it's pretty much identical to reflected XSS.

Let's say our application depends on an external resource—the app embeds an <iframe> for showing trailers for the K-Dramas and sets the iframe's src attribute to an external site. So our code might look like this.

<iframe src="{resourceURL}" />

We usually call out to the third-party service to get the URLs for the source, but agitators have infiltrated this third-party service and now control the resource URLs returned, making our code look like this.

<iframe src="javascript:alert('Boo!')" />

Well, darn it, we've got some problems.

XSS support in Angular

Fortunately, Angular has a lot of built-in security protections. It treats all values as suspicious and untrusted by default, which is incredibly helpful because the framework automatically guards us against unintentionally creating vulnerabilities in our applications. Angular automatically removes any script tags so we won't have to worry about the original hypothetical example.

Let's see some examples of how Angular protects us against XSS.

Angular automatically escapes values

Web applications implement comment features like in the Stored XSS example by calling an API to get a list of comments, then add the comments to the template. In Angular, an extremely simplified comments component might look something like this:

@Component({
  selector: 'app-comments'
  template: `
    <p *ngFor="let comment of comments | async">
      {{comment}}
    <p>
  `
})
export class CommentsComponent implements OnInit {
  public comments: Observable<string[]>;

  constructor(private commentsService: CommentsService) { }

  public ngOnInit(): void {
    this.comments = this.commentsService.getComments();
  }
}

The XSS attack vector works only if the web app treats all values as trustworthy and appends them directly to the template, such as when the web app doesn't escape or sanitize values first. Luckily, Angular automatically does both.

When you add values through interpolation in templates (using the {{}} syntax), Angular automatically escapes the data. So the comment:

<a href="javascript:alert(\'Crash Landing on You stinks!\')">Click to win a free prize!</a>

displays exactly like what's written above as text. It's still a terrible comment and unfriendly to "Crash Landing on You" fans, but it doesn't add the anchor element to the app. This is awesome because even if the attack were more malicious, it still wouldn't perform any actions.

Angular automatically sanitizes values

Let's say we want to display the comments preserving any safe markup a user enters. We already have two malicious comments to start us off on shaky ground:

<a href="javascript:alert(\'Crash Landing on You stinks!\')">Click to win a free prize!</a>
<img src=1 onerror="alert('Doh!')"/>

Then a K-Drama fan adds a new comment with safe markup.

<strong>It's a wonderful drama! The best!</strong>

Because the CommentsComponent uses interpolation to populate the comments, the comments will display in the browser in text like this:

That's not what we want! We want to interpret the HTML and allow the <strong> text, so we change our component template to bind it to the HTML innerHTML property.

<p 
  *ngFor="let comment of comments | async" 
  [innerHTML]="comment"
> 
<p>

Now, the site displays only the second comment correctly formatted like this:

The first comment with the anchor tag doesn't display the alert when clicked! The second comment with the attack in the onerror handler only shows the broken image and doesn't run the error code! Angular doesn't publish a list of unsafe tags. Still, we can sneak a peek into the codebase to see Angular considers tags such as form, textarea, button, embed, link, style, template as suspicious and may altogether remove the tag or remove specific attributes/child elements.

As we learned earlier, sanitizing removes suspicious code while keeping safe code. Angular automatically strips out unsafe attributes from safe elements. You will see a warning in the console letting you know Angular cleaned the content up.

By handling values "the Angular way," our application is well protected against security woes! Success!

Bypassing Angular's security checks

🚨 Here be dragons! 🚨

Be careful about bypassing the built-in security mechanism; if you need to, read this section carefully:

What if you need to bind trusted values that Angular thinks are unsafe? You can mark values as trusted and bypass the security checks.

Let's look at the example of the image with an error handler. Instead of the value coming from an agitator, let's say there's a legitimate need to bind the image with dynamic error handling.

Sidenote - there are better ways to handle images with error handling in Angular if your application doesn't need to be quite so dynamic. Consider using an image element and bind to (error) instead, or even HostListener. Or, there are many tutorial examples of handling it cleanly using a Directive. Indeed, there are lots of better options. You should always prefer the standard Angular way using Angular building blocks. The code will be way easier to support.

Back to the example, then. In the example above, we saw that the error handler didn't run. Angular stripped it out. We need to mark the code as trusted for the error code to run.

Your component code might look like this.

@Component({
  selector: 'app-trustworthy-image',
  template: `
    <section [innerHTML]="html"
  `
})
export class TrustworthyImageComponent {
  public html = `<img src=1 onerror="alert('Doh!')"/>`;
}

You see the broken image in the browser, and no alert pops up.

We can use the DomSanitzer class in @angular/platform-browser, to mark values as safe. The DomSanitizer class has built-in sanitization methods for four types of contexts:

HTML - binding to add more content like this innerHTML image example
Style - binding styles to add more flair to the site
URL - binding URLs like when you want to navigate to an external site in an anchor tag
Resource URL - binding URLs that load and run as code

To mark the value as trusted and safe to use, you can inject DomSanitizer and use one of the following methods appropriate for the security context to return a value marked as safe.

bypassSecurityHTML
bypassSecurityScript
bypassSecurityTrustStyle
bypassSecurityTrustUrl
bypassSecurityTrustResourceUrl

These methods return the same input but are marked as trusted by wrapping it in a safe equivalent of the sanitization type.

Let's see what this component looks like when we mark the HTML value as trusted.

@Component({
  selector: 'app-trustworthy-image',
  template: `
    <section [innerHTML]="html"
  `
})
export class TrustworthyImageComponent {
  public html = `<img src=1 onerror="alert('Doh!')"/>`;
  public safeHtml: SafeHtml;

  constructor(sanitizer: DomSanitizer) {
    this.safeHtml = sanitizer.bypassSecurityTrustHtml(this.html);
  }
}

Now, if you view this in the browser, you'll see the broken image and an alert pop up. Success?? Maybe...

Let's look at an example with a resource URL, such as the DOM-based XSS example where we bind the URL of the iframe source.

Your component code might look like this

@Component({
  selector: 'app-video',
  template: `
    <iframe [src]="linky" width="800px" height="450px"
  `
})
export class VideoComponent {

  // pretend this is from an external source
  public linky = '//videolink/embed/12345';
}

Angular will stop you right there. 🛑

You'll see an error in the console saying unsafe values can't be used in a resource URL. Angular recognizes you're trying to add a resource URL and is alarmed you're doing something dangerous. Resource URLs can contain legitimate code, so Angular can't sanitize it, unlike the comments we had above.

If we are sure our link is safe and trustworthy (highly debatable in this example, but we'll ignore that for a moment), we can mark the resource as trusted after we do some cleanup to make the resource URL safer.

Remember, we should only use the bypassSecurityTrust... methods if we know the value is trustworthy. You bypass the built-in security mechanisms and open yourself to security vulnerabilities!

Instead of using the entire video URL based on the external party's API response, we'll construct the URL by defining the video host URL within our app and appending the video's ID that we get back from the external party's API response. This way, we aren't entirely reliant on a potentially untrustworthy value from a third party. Instead, we'll have some measure of ensuring we're not injecting malicious code into the URL.

Then we'll mark the video URL as trusted and bind it in the template. Your VideoComponent changes to this:

@Component({
  selector: 'app-video',
  template: `
    <iframe [src]="safeLinky" width="800px" height="450px"
  `
})
export class VideoComponent {

  // pretend this is from an external source
  public videoId = '12345';
  public safeLinky!: SafeResourceUrl;

  constructor(private sanitizer: DomSanitizer) {
    this.safeLinky = sanitizer.bypassSecurityTrustResourceUrl(`//videolink/embed/${this.videoId}`)
  }
}

Now you'll be able to show trailers of the K-Dramas on your site in an iframe in a much safer way.

It can't be stressed enough. Ensure you trust the values before bypassing the out-of-the-box security protections you get from Angular!

Great! So we're done? Not quite. There are a couple of things to note.

Use ahead-of-time (AOT) compilation for extra security

Angular's AOT compilation has extra security measures for injection attacks like XSS. AOT compilation is highly recommended for production code and has been the default compilation method since Angular v9. Not only is it more secure, but it also improves performance.

On the flip side, the other form of compilation is Just-in-time (JIT). JIT was the default for older versions of Angular. JIT compiles code for the browser on the fly, and this process skips Angular's built-in security protection, so stick with using AOT.

Don't concatenate strings to construct templates

Angular trusts template code and only escapes values defined in the template using interpolation. So if you attempt something clever to circumvent the more common forms of defining the template for a component, you won't be protected.

For example, you won't have Angular's built-in protections if you try to dynamically construct templates combining HTML with data using string concatenation or have an API whip up a payload with a template you somehow inject into the app. Your clever hacks with dynamic components might cause you security woes.

Beware of constructing DOM elements without using Angular templates

Any funny business you might try using ElementRef or Renderer2 is the perfect way to cause security issues. For example, you can pwn yourself if you try to do something like this.

@Component({
  selector: 'app-yikes',
  template: `
    <div #whydothis></div>
  `
})
export class YikesComponent implements AfterViewInit {

  @ViewChild('whydothis') public el!: ElementRef<HTMLElement>;

  // pretend this is from an external source
  public attack = '<img src=1 onerror="alert(\'YIKES!\')"';

  constructor(private renderer: Renderer2) { }

  public ngAfterViewInit(): void {

    // danger below!
    this.el.nativeElement.innerHTML = this.attack;
    this.renderer.setProperty(this.el.nativeElement, 'innerHTML', this.attack);
  }
}

Something like this might be tempting in a fancy custom directive, but think again! Besides, interacting directly with the DOM like this isn't the best practice in Angular, even beyond any security issues it might have. It's always wise to prefer creating and using Angular templates.

Explicitly sanitize data

The DomSanitizer class also has a method to sanitize values explicitly.

Let's say you cook up a legitimate need to use ElementRef or Render2 to build out the DOM in code. You can sanitize the value you add to the DOM using the method sanitize(). The sanitize() method takes two parameters, the security context for the sanitization and the value. The security context is an enumeration matching the security context listed previously.

If we redo the YikesComponent to explicitly sanitize, the code looks like this.

@Component({
  selector: 'app-way-better',
  template: `
    <div #waybetter></div>
  `
})
export class WayBetterComponent implements AfterViewInit {

  @ViewChild('waybetter') public el!: ElementRef<HTMLElement>;

  // pretend this is from an external source
  public attack = '<img src=1 onerror="alert(\'YIKES!\')"';

  constructor(private renderer: Renderer2, private sanitizer: DomSanitizer) { }

  public ngAfterViewInit(): void {

    const cleaned = this.sanitizer.sanitize(SecurityContext.HTML, this.attack);
    this.renderer.setProperty(this.el.nativeElement, 'innerHTML', cleaned);
  }
}

Now you'll have the image without the potentially dangerous code tagging along for the ride.

Consider Trusted Types

One more built-in security mechanism in Angular is setting up and using a Content Security Policy (CSP). CSPs are a specific HTTP security header we covered in the first post to help set up foundational security mechanisms.

Angular has built-in support for defining policies for a CSP called Trusted Types. Trusted Types are a great way to add extra XSS security guards to your Angular app but isn't supported across all the major browsers yet. If you are interested in learning more about setting up the Trusted Types CSP for SPAs, check out this great post from the Auth0 blog - Securing SPAs with Trusted Types.

Learn more about XSS, Trusted Types, and creating applications using Angular

This series taught us about web security, common web attacks, and how Angular's built-in security mechanisms protect us from accidental attacks.

If you liked this post, you might be interested in these links.

Don't forget to follow us on Twitter and subscribe to our YouTube channel for more great tutorials. We'd also love to hear from you! Please comment below if you have any questions or want to share what tutorial you'd like to see next.

Protect Your Angular App From Cross-Site Request Forgery

Alisa — Tue, 26 Jul 2022 15:22:11 +0000

Previously, I wrote about web security at a high level and the framework-agnostic ways to increase safety and mitigate vulnerabilities.

Now, I want to dive a little deeper into the vulnerabilities. In this short post, we'll dive into Cross-Site Request Forgery (CSRF) and look at the built-in help you get when using Angular.

Cross-Site Request Forgery (CSRF) protection

In the previous post, you learned how an attack for CSRF occurs when an agitator uses your active session for a trusted site to perform unauthorized actions. We also learned there's built-in support from browsers to mitigate attacks with SameSite attributes on cookies, validating the authenticity of the request on the backend, and potentially having the frontend send a CSRF token to the backend for every request.

The mitigation strategies primarily require server-side work, except for that game of CSRF token sending, where the client needs to send the token back in a way the backend can validate.

When using CSRF tokens, it's essential to tie the token to the user's session so that the backend can validate the request. The most common ways are through the patterns called Synchronizer Token Pattern and Double Submit Cookie.

Synchronizer Token Pattern

The Synchronizer Token Pattern requires the backend to store the user's session information and match it up with the CSRF token for validity. This pattern can be used with SPAs but is a better match for web apps that use forms with post methods for requests, such as:

<form action="https://myfavekdramas.com/fave-form" method="POST">
  <label for="name">What is your favorite K-Drama?</label>
  <input type="text" id="name" name="name">
  <button>Save my favorite K-Drama</button>
</form>

Submitting this form POSTs to https://myfavekdramas.com/fave-form using the application/x-www-form-urlencoded content type. CSRF is especially susceptible when using non-JSON data.

Double Submit Cookie Pattern

Sadly, this pattern doesn't involve double the cookies—it's a dual submission. Sad news indeed for chocolate-chip cookie fans. 🍪🍪 😢 But the good news is the Double Submit Cookie Pattern doesn't require the backend to track the user's session to the CSRF token.

In this pattern, the CSRF token is a separate cookie from the user's session identifier. The client sends the CSRF token in every request, and the backend validates that the CSRF token cookie and the token in the request values match. This pattern is more common for SPAs.

CSRF support in Angular

Angular has built-in support for a flavor of the Double Submit Cookie Pattern, where the CSRF token is automatically added as an HTTP header for every backend request once you have a CSRF token in a cookie. Nice!

The HttpClientXsrfModule automatically adds an interceptor for your HTTP requests. The interceptor grabs the CSRF token from a session cookie named XSRF-TOKEN and adds the token value to outgoing requests in the HTTP header named X-XSRF-TOKEN. Then your backend is responsible for verifying the values for the cookie and HTTP header match.

To add this handy helper, add HttpClientModule and the HttpClientXsrfModule to your module's imports array.

If you don't like the default names, you have the option of configuring the names of the cookie and HTTP header like this:

imports: [
  HttpClientModule,
  HttpClientXsrfModule.withOptions({
    cookieName: 'Pecan-Sandies',
    headerName: 'Top-Of-Page'
  })
]

Learn more about CSRF and creating applications using Angular

Watch for the fourth and final post in this series, as we dive into Cross-Site Scripting (XSS) and learn how Angular's built-in security mechanisms protect us.

If you liked this post, you might be interested in these links.

Defend Your SPA From Common Web Attacks

Alisa — Thu, 21 Jul 2022 14:35:29 +0000

This is the second post in a series about web security for SPAs. In the last post, we laid the groundwork for thinking about web security and applying security mechanisms to our application stack. We covered the OWASP Top Ten, using secure data communication with SSL/TLS, using security headers to help enhance built-in browser mechanisms, keeping dependencies updated, and safeguarding cookies.

Ready to continue and make your SPA safer? This post will use the concepts we introduced to banish some well-known web vulnerabilities.

Practice data cleanliness to mitigate XSS

Cross-Site Scripting (XSS) is a vulnerability that continues to plague web developers. This vulnerability is a type of injection attack and is so common that it's number 3 on the OWASP Top Ten list.

How does this vulnerability work? In short, XSS happens when code pollutes data, and you don't implement safeguards.

Ok, fine, but what does that mean? A classic example is a website that allows user input, like adding comments or reviews. Suppose the input form accepts anything the user types in and doesn't appropriately safeguard that user input before storing and displaying it to other users. In that case, it's at risk for XSS.

Imagine an overly dramatic but otherwise innocent scenario like this:

A website allows you to add comments about your favorite K-Drama.

An agitator adds the comment <script>alert('Crash Landing on You stinks!');</script>.

That terrible comment saves as is to the database.

A K-Drama fan opens the website.

The terrible comment is added to the website, appending the <script></script> tag to the DOM.

The K-Drama fan is outraged by the JavaScript alert saying their favorite K-Drama stinks.

So, this is obviously awful. Least of all because we all know "Crash Landing on You" is, in fact, wonderful. Also, this scenario exposes your website to the possibility of a colossal breach in which an injection attack can do all sorts of bad things. With JavaScript, the attack could grab cookies, dig around your browser's local storage for authentication information, access your file system, make calls to other sites, and do even more harm.

In this case, we've show an example very clearly using a <script></script> tag to make it easier for us to talk about, but an attack can use anything that runs JavaScript, such as adding an HTML element with JS embedded in the attribute, adding JS to resource URLs, embedding JS into CSS, and so forth. This is the true stuff of nightmares!

How do we avoid these sorts of shenanigans? There are a few different defensive tactics, but the main one is to ensure you practice good data hygiene through escaping and sanitizing.

Escaping refers to replacing certain specific characters in HTML so they are read as text strings, such as replacing <b> with <b>). When you escape, the browser no longer treats the value as part of the code. It's simply text or data. Although we're talking XSS here, escaping is a good practice in general as it will protect you against SQL injection, a different type of injection attack.

-- xkcd

Sanitizing removes code that might be malicious, while preserving some safe HTML tags. The primary use case for choosing to sanitize instead of to escape the code is when you want to allow markup to display, like if you have a rich text editor on your website.

There's a lot more to discuss regarding cross-site scripting, including types of XSS and mitigation technique specifics, so keep an eye out for a follow-up post with more details, including the built-in XSS security mechanisms provided in some SPA frameworks.

Dive into XSS

Can't wait to read more about XSS? Check out these resources that cover how cross-site scripting works:

Validate requests for authenticity to mitigate CSRF

Cross-Site Request Forgery (CSRF) is another well-known vulnerability in the top spot of the OWASP Top Ten, Broken Access Control. CSRF allows attackers to exploit your identity to perform unauthorized actions. Sounds pretty bad, right? Well, yup, you're correct.

The exploit works like this.

You log in to the K-Drama site to upvote some recent shows you watched.

Then, in a loss of judgment, you open a spam email and click the link to transfer money to an agitator claiming to be your long lost high school sweetheart. (What were you thinking!)

The link takes you to a malicious site with a hidden form embedded within it.

The hidden form sends an HTTP POST request with terrible comments to the K-Drama site along with the active session cookie.

Since you have an active authenticated session on the K-Drama site, the POST completes as if you were the one adding terrible comments about "Hospital Playlist"!

Luckily in this example, the unauthorized action isn't irreversible or devastating. You can delete the terrible comments, and you can explain how it wasn't really you who posted such comments to horrified "Hospital Playlist" fans. However, you can see how dangerous and malicious this exploit would be if the target was something fundamental like a bank!

The only way to mitigate against CSRF is to ensure the request is legitimate.

Fortunately, we already have some tools and actions at our disposal that we covered previously, such as:

Prefer tokens in HTTP headers for authenticated HTTP calls and ideally store those tokens in-memory.
Configure tight CORS controls.
Protect your cookies!

These mechanisms are so good that some say there's nothing more you need to do for SPAs!

However, CSRF relies on your backend not completing due diligence to verify the authenticity of the requests and allowing non-JSON payloads. Hackers are very clever, and you may need to allow <form> payloads in your backend, so you may need extra safeguards. When you do need extra guards, you can add a unique CSRF token for communication between your frontend and backend. The backend needs to verify standard authentication and authorization safeguards and verify the CSRF token's legitimacy.

The token is generated by the backend and sent to the frontend. The frontend then uses the token in subsequent calls to the backend by adding it as a custom HTTP header.

For SPAs, getting that CSRF token from the server is the difficult part. In traditional web apps, it's not a problem. But for SPAs, you don't call your back-end API until after you load the application. You also want CSRF protection before logging in if you're not delegating authentication to a third-party authentication provider. 😎

The recommendation is to have your client call an endpoint on your backend to get the CSRF token. The endpoint must be super vigilant about confirming the caller's origin and keeping that CORS allowlist very strict.

Dive deeper into CSRF

There are a lot of browser protections that help us mitigate CSRF. Check out these links if you want to learn more about CSRF.

Learn more about common web attacks

Stay tuned for the next post in this series as we dive deeper into CSRF and learn how Angular helps protect against it.

Ready to learn more? Check out out the following resources.

Don't forget to follow us on Twitter and subscribe to our YouTube channel for more great tutorials. We'd also love to hear from you! If you have any questions or want to share what tutorial you'd like to see next, please comment below.

Defend Your SPA From Security Woes

Alisa — Tue, 19 Jul 2022 14:43:43 +0000

There's a lot of information floating out there about web security. But when I read through the material, I noticed some information wasn't up to date, or it was written specifically for traditional server-rendered web applications, or the author recommended anti-patterns. In a series of posts, I will cover web security concerns that all web devs should be aware of, emphasizing client-side applications, namely Single Page Applications (SPAs). Furthermore, I'm not going to get into the nitty-gritty of web security, cryptography, and networking. Instead, I'll focus on the main takeaways and high-level to-do lists. I'll also provide links to resources where you can dive in deeper.

So why do we worry about web security anyway? When we have vulnerabilities in our applications, it's an avenue for exploitation by bad actors. In the wrong hands, exploiting the vulnerabilities can cause risks to your application, data, reputation, and bottom line. In the words of my coworker Aaron Parecki, it all boils down to one thing—liability. And we don't want to expose ourselves, our applications, and our companies to liability. If you feel threatened, it's a good time to read on and identify how to harden your application.

Use the OWASP Top 10 to identify the most common vulnerabilities

If you're new to thinking about security, you may not have heard of the Open Web Application Security Project (OWASP). OWASP is a group that focuses on making the web a safer place. They maintain and publish a list of the most common web vulnerabilities named the "OWASP Top Ten" and have a new top ten list for 2021; their infographic shows how the top web vulnerabilities have changed from 2017 to 2021.

CC-by Open Web Application Security Project

As this is a list of web vulnerabilities, the entire list is pertinent to our work as web developers. However, a few critical vulnerabilities call for extra attention, and some vulnerabilities are less susceptible when the front-end is a SPA with a JSON-based backend API.

We will cover some of these vulnerabilities specifically, but I'll also list general things to keep in mind that feed into the vulnerabilities listed here.

Leverage your browser and security headers

First, we need to set the stage for part of our vulnerability mitigation strategy by bringing up security headers. Modern browsers (buh-bye Internet Explorer!!) have a lot of security mechanisms already built in. We have to leverage the built-in security mechanisms and can enhance them with additional security headers. Security headers are HTTP response headers that provide instructions on how the browser should behave. They are defined on your web server.

There are quite a few security headers that we can apply. Something to note, SPAs are unique, so not all security headers apply in the same way as they would for a traditional server-rendered web application. I'll call out the security headers that you'll want to use when we discuss how to mitigate a specific vulnerability.

Dive deeper into security headers

Here are some great resources to learn more about security headers. Figuring out how to configure the security headers can be esoteric. I like these posts that are short and offer actionable steps to configure security headers.

Securely transport data using TLS/SSL

Using HTTPS should be the undisputed standard, but there are legacy systems where applications don't use HTTPS. It's essential to use the secure hypertext transfer protocol; after all, the HTTPS acronym is appropriately derived from Hypertext Transfer Protocol Secure. And it's essential to be secure across your entire stack, not just when serving the front-end site (don't ask me how I know this can be a thing).

When you don't use an up-to-date Transport Layer Security within your application system, you expose yourself to meddler-in-the-middle attacks (MITM). In this type of attack, agitators intercept communication between unsecured systems to siphon data or impersonate communicating parties.

You might think this callout to use HTTPS is unnecessary because it's such a standard for hosting web apps, but cryptographic failures that cause insecure communication are the second most common vulnerability in the OWASP Top Ten! Note that it's not enough to slap any old mechanism for HTTPS on your web server. You want a recent version of TLS. Your cloud providers might even force you to upgrade if your TLS version is old, which is good!

-- xkcd

What's the takeaway here? Specifically, you'll want to make sure you have functioning certificates, ensure you're using the latest version of TLS, and make sure you use SSL/TLS over your entire stack. All of these steps might already be covered by your cloud hosting provider. You should also verify you've added the HTTP Strict Transport Security (HSTS) security header to the web server, which adds an extra layer of security beyond HTTPS redirection.

Dive deeper into transport layer security

Check out these resources if you want to read more about Transport Layer Security and how to set up HTTPS redirection and HTST.

Keep your framework and external dependencies up to date

You knew this was coming, even though we might lament the work involved to stay up to date. The advice to update your dependencies sounds like "Don't forget to floss," but it's essential (just like flossing). Vulnerable and outdated components take the sixth spot in the OWASP Top Ten list. And there were some significant vulnerabilities from dependencies in the news recently. So you know deep down that burying your head in the sand is not a good action plan.

It's important to note that we should update outdated components and ensure we don't accidentally depend on a vulnerable dependency. We should pin dependency versions in our package.json and then generate and enforce the use of a lock file. That means running npm ci instead of npm i to force the exact versions defined in the package-lock.json. If you use Yarn, you will use yarn install --frozen-lockfile. This way, updating versions is an intentional act.

That's it. Just do it. It's important. Outdated components are a source of liability.

Dive deeper into keeping your components up to date

Check out a step-by-step guide on dependency management for JavaScript developers by the OWASP team - NPM Security best practices.

Load resources securely

Cross-origin resources are a particular concern for SPAs; this refers to resources your web app uses that are not hosted on the same origin as your web application. When all the resources the front-end needs are available through the same origin, we have confidence that the resources are secure. Hopefully, we're not pwning ourselves! At least not intentionally, right?!

A typical pattern for setting up URLs for SPA communicating to back-end APIs might look like the following, where your front-end is

https://myfavekdramas.com

and the back-end API URL is

https://apis.myfavekdramas.com

But the API URL is a subdomain, so the request is cross-origin. Most browsers (once again BUH-BYE Internet Explorer!) protect us by allowing only specific cross-origin requests. We can configure resource access by enabling Cross-origin Resource Sharing (CORS).

Between your production environment setup resembling the above URLs, and local development using different ports for your front-end and back-end, you might be tempted to enable CORS to allow all sorts of requests. Unlike other security measures covered in this post, your browser already protects you in the strictest way possible. Enabling CORS loosens that restriction.

So the advice is to enable CORS appropriately with considered use of allowlists. Use proxies as appropriate (such as for local development). The concept of least privilege applies here too, and keeping a tight lid on things helps mitigate security vulnerabilities.

Dive into cross-origin resource sharing

Want to understand better when CORS rules apply or how to set up the allowlist rules? Read these resources for a deep dive.

Protect your cookies from theft

Really, this advice is applicable outside of web development too. But since we're talking about web development in this post, we'll skip mitigation strategies about protecting your physical cookies from marauders and focus again on security headers.

Cookies can contain all sorts of goodies, such as chocolate chips and the tidbits of data that agitators love to have! Current authentication best practices favor using in-browser memory or web workers for authentication tokens over cookies, and cookies should never be used for secrets, but there might still be sensitive information stored in cookies. To help protect cookies, we can use attributes.

Cookies should be temporary. In particular, cookies with sensitive information should be as short-lived as possible. When you or your back-end bakes up a cookie, adding the attribute Max-Age defines the longevity of the cookie.

There are some more attributes you can bake in! Adding the httpOnly attribute means the browser only sends a cookie for HTTP requests, and JavaScript won't be able to access cookies. Setting the httpOnly attribute is an excellent first step to guarding your cookies against a malicious script that can read your cookies.

Having the httpOnly attribute means that JavaScript can't access the cookie, but it doesn't mean your browser carefully curates which cookies to send to each HTTP request! It just sends them all, resulting in the possibility of a vulnerability!

This is where the SameSite attribute comes into play. You can control when cookies should be sent by using the SameSite attribute and setting one of 3 values:

Strict - only send cookies if they are going to the same site that requested them.
Lax - only send cookies when the user is navigating to the origin site. (This is the default behavior now for Chromium-based browsers.)
None - send the cookies to everyone, everywhere. As a safeguard for your generous behavior, which is concerning to the browser, you're also required to add the Secure attribute.

With the SameSite attribute set, you can no longer have a scenario like this

Be thoughtful about cookies and apply principles of least privilege. Safeguarding cookies is a big step in mitigating other vulnerabilities.

Dive deeper into cookie guarding

Learn more about protecting your cookies by checking out these fantastic resources.

Learn more about web security

Stay tuned for the next post in this series as we learn about two well-known web security attacks, along with mitigation techniques using what we covered here.

Can't wait to learn more? Check out out the following resources.

Secure and Deploy Micro Frontends with Angular

Alisa — Wed, 25 May 2022 15:01:30 +0000

Micro frontends continue to gain interest and traction in front-end development. The architecture models the same concept as micro services - as a way to decompose monolithic front-end applications. And just like with micro services, micro frontends have complexities to manage.

This post is part two in a series about building an e-commerce site with Angular using micro frontends. We use Webpack 5 with Module Federation to wire the micro frontends together, demonstrate sharing authenticated state between the different front ends, prepare for deployment using dynamic module loading, and deploy it all to Vercel's free hosting plan.

In this second post, we're building on the site we created in part one, How to Build Micro Frontends Using Module Federation in Angular.

How to Build Micro Frontends Using Module Federation in Angular

Alisa for Okta ・ May 24 '22

#angular #webdev #tutorial #frontend

Let's add dynamic module loading to our cupcake e-commerce site, secure unprotected routes, and set up the site for deployment in Vercel, a service designed to improve the front-end development workflow. 🎉

In the end, you'll have an app that looks like this publicly available through Vercel:

Prerequisites

Node This project was developed using Node v16.14 with npm v8.5
Angular CLI
GitHub Account
Vercel Account connected through your GitHub credentials for automating deployment.

Review the Angular micro-frontends project using Webpack and Module Federation

Let's start by refreshing our memories—dust off your project from the first post. Just like last time, we'll need both IDE and the terminal.

We have the host application, shell, and two micro-frontend remotes, mfe-basket and mfe-profile. We're using @angular-architects/module-federation to help facilitate the Module Federation plugin configuration. The cupcake basket functionality code resides in the shared library, and we share authenticated state using Okta's SDKs.

Serve all of the Angular applications in the project by running:

npm run run:all

When you run the project, you should see all the beautiful cupcakes this store sells. You'll be able to sign in, view your profile, add items to your basket, view your cupcake basket, and sign out. All the basics for handling your sweet treat needs!

Note: If you want to skip the first post and follow along with this tutorial, you can clone the code sample repo to get going. You will be missing quite a bit of context, though. Use the following commands in this case:

git clone --branch local https://github.com/oktadev/okta-angular-microfrontend-example.git
npm ci
npm run run:all

You'll need to follow the instructions on creating the Okta application and updating the code with your Okta domain and client ID.

Dynamic loading of micro-frontend remotes

So far, we've been serving the cupcake micro-frontend website using the npm script run:all, which serves all three applications at once. Let's see what happens if we only try serving the host application. Stop serving the site, run ng serve shell to serve the default application, shell, and open the browser.

When you navigate to http://localhost:4200, you see a blank screen and a couple of console errors. The console errors happen because shell can't find the micro-frontend remotes at ports 4201 and 4202. 👀

These errors mean the host is loading the micro frontends upon initialization of the host, not upon route change like you might think based on configuring a lazy-loaded route in the routing module. Doh!

With the @angular-architects/module-federation library's loadRemoteModule() method, we can dynamically load the micro-frontend remotes upon route change with a few quick changes.

Open projects/shell/src/app/app-routing.module.ts.

The function we pass into the loadChildren property for the lazy-loaded routes changes to using loadRemoteModule(). Update your routes array to match the code below.

import { loadRemoteModule } from '@angular-architects/module-federation';

const routes: Routes = [
  { path: '', component: ProductsComponent },
  {
    path: 'basket',
    loadChildren: () => loadRemoteModule({
      type: 'module',
      remoteEntry: `http://localhost:4201/remoteEntry.js`,
      exposedModule: './Module'
    }).then(m => m.BasketModule)
  },
  {
    path: 'profile',
    loadChildren: () => loadRemoteModule({
      type: 'module',
      remoteEntry: `http://localhost:4202/remoteEntry.js`,
      exposedModule: './Module'
    }).then(m => m.ProfileModule)
  },
  { path: 'login/callback', component: OktaCallbackComponent }
];

Now that you're loading the remotes within the route definitions, you no longer need to define the remote URI in the projects/shell/webpack.config.js. Go ahead and remove or comment out the remotes in the webpack.config.js file. Another benefit of dynamic remote loading is that we no longer need to declare the modules to help TypeScript. Feel free to delete the projects/shell/decl.d.ts file. 🪄

Double-check everything still works by running npm run run:all.

Then stop serving the project and try running only the shell application by running the following command:

ng serve shell

You should now see the shell application and only see a console error when navigating to a route served by a micro-frontend remote. Success!

Deploy your micro-frontend project using Vercel

Now that the cupcakes site is working locally let's deploy this beautiful website using Vercel. Ensure you've authorized Vercel access to GitHub because we'll take advantage of the built-in integration to deploy changes from the main branch automatically.

First, push your project up to a GitHub repo. If you wish to obscure your Okta configuration, you can make the repo private. The Okta configuration code is not confidential information, as single-page applications are public clients. If you don't like committing the configuration values into code, you can load the configuration values at runtime or use environment variables as part of your build step. I won't get into the details of how to handle that here, but I will include some links at the end. Make sure to leave the checkbox for Initialize this repository with a README unchecked.

In the Vercel dashboard, press the + New Project button to import a Git repository. Depending on what permissions you granted to Vercel, you might see your newly created GitHub repo immediately. If not, follow the instructions to adjust GitHub app permissions and allow Vercel access to the repo. Press the Import button for the repo to continue. You'll see a form to configure the project within Vercel.

The idea behind micro frontends is to be able to deploy each application independently. We can do this in Vercel by creating a separate project for each application. Vercel limits the number of projects for a single repo to three in the free plan. What an extraordinary coincidence!

First, we'll configure the project for the micro-frontend host, the shell application. To keep the projects organized, incorporate the application name into the Vercel project name, such as okta-angular-mfe-shell. You'll also need to update the build command and output directory for the shell application. Update your configuration to look like the screenshot below.

Press the Deploy button to kick off a build and deploy the application.

You'll see a screenshot of the application and a button to return to the dashboard when finished. On the dashboard, you'll see the deployed URI for the application and a screenshot of the cupcakes storefront. If you visit the URI, the routes won't work yet if you try navigating to the remotes. We need to deploy the remote projects and update the URI to the remotes in the route definition. Keep that URI for the shell application handy; we'll use it soon.

Return to the Vercel dashboard, create a new project, and select the same repo to import. This time we'll configure the remote application mfe-basket. Update your configuration to look like the screenshot below.

Take note of the deployed URI for the mfe-basket application.

Return to the Vercel dashboard to repeat the process for the final remote application, mfe-profile. Update your configuration to look like the screenshot below.

Take note of the deployed URI for the mfe-profile application.

Update the routes to support micro-frontend paths for production

We need to update the route definition to include the URI for the deployed application. Now that you have the URI for the two micro-frontend remotes, you can edit projects/shell/app/app-routing.module.ts. The values in the remoteEntry configuration option in the loadRemoteModule() method are where you'd define the path. But if we update this value to use the deployed URI, then you'll no longer be able to run the application remotely.

We'll use the environments configuration built into Angular to support both local and deployed environments and define a configuration for serving locally versus production build.

We'll configure serving locally first. Open projects/shell/src/environments/environment.ts and add a new property for the micro-frontend remotes.

export const environment = {
  production: false,
  mfe: {
    "mfeBasket": "http://localhost:4201",
    "mfeProfile": "http://localhost:4202"
  }
};

Next, we'll use the values in the route definition. Open projects/shell/src/app/app-routing.module.ts and update the remoteEntry properties to use the new properties in the environment.ts file below.

import { environment } from '../environments/environment';

const routes: Routes = [
  { path: '', component: ProductsComponent },
  {
    path: 'basket',
    loadChildren: () => loadRemoteModule({
      type: 'module',
      remoteEntry: `${environment.mfe.mfeBasket}/remoteEntry.js`,
      exposedModule: './Module'
    }).then(m => m.BasketModule)
  },
  {
    path: 'profile',
    loadChildren: () => loadRemoteModule({
      type: 'module',
      remoteEntry: `${environment.mfe.mfeProfile}/remoteEntry.js`,
      exposedModule: './Module'
    }).then(m => m.ProfileModule)
  },
  { path: 'login/callback', component: OktaCallbackComponent }
];

Feel free to serve the project using npm run run:all to double-check everything still works.

Now we'll add the configuration for the deployed applications. Open projects/shell/src/environments/environment.prod.ts and add the same property for the micro-frontend remotes. Replace the URI with the deployed location.

export const environment = {
  production: true,
  mfe: {
    "mfeBasket": "https://{yourVercelDeployPath}.vercel.app",
    "mfeProfile": "https://{yourVercelDeployPath}.vercel.app"
  }
};

Angular automatically replaces the environment.ts file to match when you build the project. So if you're serving locally, you'll use the contents from environment.ts, and if you run ng build to create the release, you'll use the contents from environment.prod.ts.

Note: Vercel has a release promotion mechanism where you first release to a staging environment to conduct release verification, then promote the verified application to prod. With this flow, we'd need to add more complexity to the way we access the URIs. This tutorial will simplify things to only use one environment, but if you need to handle a multi-step release environment configuration, check out the links to blog posts at the end for handling per-environment configuration.

Add your deployment URL to Okta

You'll need to update the Okta application with the new deploy location so that you can sign in. Open the Okta dashboard. Navigate to Applications > Applications and select the Okta application you created for this project. On the General tab, press the Edit button on the General Settings section and add the new deploy URI for the shell application.

Next, add the deploy URI as a Trusted Origin in Okta. Navigate to Security > API and then navigate to the Trusted Origins tab. Press + Add Origin. Add the deploy location and select CORS for the type.

Commit your changes and push to your main branch. After the build succeeds, you should be able to use the deployed site from end to end!

Secure your micro frontends

Right now, you can access what should be protected routes by manually typing in the full URI to the profile route. Even though you don't see any profile information, we aren't guarding the route. Let's make the site a little more secure by protecting the route.

Open projects/shell/src/app/app-routing.module.ts. We'll add a route guard that comes out of the box with Okta's Angular SDK. Update the route definition for the profile route as shown below.

import { OktaCallbackComponent, OktaAuthGuard} from '@okta/okta-angular';

{
  path: 'profile',
  loadChildren: () => loadRemoteModule({
    type: 'module',
    remoteEntry: `${environment.mfe.mfeProfile}/remoteEntry.js`,
    exposedModule: './Module'
  }).then(m => m.ProfileModule),
  canActivate: [OktaAuthGuard]
},

Now if you navigate directly to the profile route, you'll first redirect to Okta's sign-in page, then redirect back to the profile route.

Route protection works well from within the micro-frontend shell. But what if you navigate directly to the URI where the profile micro frontend resides? You will still be able to navigate to the profile route within the micro frontend because there isn't a guard within the profile application.

This brings us to an interesting concept. In order to fully secure your micro frontends, you should protect routes defined within your micro frontend as well. To add the Okta route guard, you'll need to import the OktaAuthModule into the mfe-profile application's AppModule, and add the same configuration as you did for the shell application. The Module Federation configuration shares the Okta library between the applications when accessed via the host application. In contrast, mfe-profile will need its own instance of authenticated state when accessed in isolation from the shell application. Having its own instance of authenticated state means you should add sign-in and sign-out capability in the AppComponent of the mfe-profile application too. This will also allow you to test each micro-frontend application independently.

Security + testing = winning!

Build the micro frontend on a relevant change

As mentioned in this post, the value of micro frontends is the ability to deploy each application independently. In production systems, you may need to handle multiple build steps and build out an entire workflow of CI/CD, but for this tutorial, we can cheat a little and still get the benefits of separate deployments. We will add a configuration in Vercel only to kick off a build when there's changes in the relevant application code.

From the Vercel dashboard, open the Vercel project for the mfe-basket application. Navigate to the Settings tab and select Git. In the Ignored Build Step, we can add a Git command to ignore all changes except those in the projects/mfe-basket directory.

Add the following command:

git diff --quiet HEAD^ HEAD ./projects/mfe-basket

Next, open the Vercel project for the mfe-profile application to update the Ignored Build Step command. Now add this command:

git diff --quiet HEAD^ HEAD ./projects/mfe-profile

Lastly, open the Vercel project for the shell application to update the Ignored Build Step command. This command is a little different because we want to pick up any changes to the project excluding this changes to mfe-basket and mfe-profile. Add the following command:

git diff --quiet HEAD^ HEAD -- ':!projects/mfe-basket' ':!projects/mfe-profile'

Now, if you make a change in a micro-frontend application, only that micro-frontend application will build and deploy. All three projects will notice the change and start building but will immediately cancel the build if the build step should be ignored for the project.

Beyond this post

I hope you've enjoyed creating and deploying this micro-frontend e-commerce site with beautiful pictures of tasty cupcakes. In this post, we used dynamic module loading to load micro frontends lazily within the host application, deployed the project to Vercel, added in multi-environment route configuration, and leveraged a micro-frontend benefit by enabling deployment upon relevant changes. You can check out the completed code for this project in the deploy branch of the code repo by using the following command:

git clone --branch deploy https://github.com/oktadev/okta-angular-microfrontend-example.git

oktadev / okta-angular-microfrontend-example

Starter code + completed project for micro-frontends using Webpack 5 and Module Federation plugin in Angular and sharing authenticated state

Angular Micro Frontend Example

This repository shows you how to set up micro frontends using Webpack 5 and Module Federation plugin in Angular and share authenticated state across the project. Please read How to Build Micro Frontends Using Module Federation in Angular to see how it was created.

This repo accompanies the posts for the Angular micro-frontend series. The starter project is in the main branch. The completed code for the first post is in the local branch.

Prerequisites

Node 16
Okta CLI
Angular CLI
GitHub account
Vercel account

Okta has Authentication and User Management APIs that reduce development time with instant-on, scalable user infrastructure. Okta's intuitive API and expert support make it easy for developers to authenticate, manage and secure users and roles in any application.

Getting Started

To run this example, run the following commands:

git clone https://github.com/oktadev/okta-angular-microfrontend-example.git
cd okta-angular-microfrontend-example
npm ci

Create

…

View on GitHub

Learn about Angular, microservices, OpenIDConnect, managing multiple deployment environments, and more

Want to learn more? If you liked this post, check out the following.

Don't forget to follow us on Twitter and subscribe to our YouTube channel for more exciting content. We also want to hear from you about what tutorials you want to see. Leave us a comment below.

How to Build Micro Frontends Using Module Federation in Angular

Alisa — Tue, 24 May 2022 15:05:38 +0000

The demands placed on front-end web applications continue to grow. As consumers, we expect our web applications to be feature-rich and highly performant. As developers, we worry about how to provide quality features and performance while keeping good development practices and architecture in mind.

Enter micro-frontend architecture. Micro frontends are modeled after the same concept as microservices, as a way to decompose monolithic frontends. You can combine micro-sized frontends to form a fully-featured web app. Since each micro frontend can be developed and deployed independently, you have a powerful way of scaling out frontend applications.

So what does the micro-frontend architecture look like? Let's say you have an e-commerce site that looks as stunning as this one:

You might have a shopping cart, account information for registered users, past orders, payment options, etc. You might be able to further categorize these features into domains, each of which could be a separate micro frontend, also known as a remote. The collection of micro-frontend remotes is housed inside another website, the host of the web application.

So, your e-commerce site using micro frontends to decompose different functionality might look like this diagram, where the shopping cart and account features are in their separate routes within your Single Page Application (SPA):

You might be saying, "Micro frontends sound cool, but managing the different frontends and orchestrating state across the micro frontends also sounds complicated." You're right. The concept of a micro frontend has been around for a few years and rolling your own micro-frontend implementation, shared state, and tools to support it was quite an undertaking. However, micro frontends are now well supported with Webpack 5 and Module Federation. Not all web apps require a micro-frontend architecture, but for those large, feature-rich web apps that have started to get unwieldy, the first-class support of micro frontends in our web tooling is definitely a plus.

This post is part one in a series where we'll build an e-commerce site using Angular and micro frontends. We'll use Webpack 5 with Module Federation to support wiring the micro frontends together. Then we'll demonstrate sharing authenticated state between the different frontends, and deploy it all to a free cloud hosting provider.

In this first post, we'll explore a starter project and understand how the different apps connect, add authentication using Okta, and add the wiring for sharing authenticated state. In the end, you'll have an app that looks like this:

Prerequisites

Node This project was developed using Node v16.14 with npm v8.5
Angular CLI
Okta CLI

Micro-frontend starter using Webpack 5 and Module Federation

There's a lot in this web app! We'll use a starter code to make sure we focus on the code that's specific to the micro frontend. If you're dismayed that you're using a starter and not starting from scratch, don't worry. I'll provide the Angular CLI commands to recreate the structure of this starter app on the repository's README.md so you have all the instructions.

Clone the Angular Micro Frontend Example GitHub repo by following the steps below and open the repo in your favorite IDE.

oktadev / okta-angular-microfrontend-example

Starter code + completed project for micro-frontends using Webpack 5 and Module Federation plugin in Angular and sharing authenticated state

Angular Micro Frontend Example

This repo accompanies the posts for the Angular micro-frontend series. The starter project is in the main branch. The completed code for the first post is in the local branch.

Prerequisites

Node 16
Okta CLI
Angular CLI
GitHub account
Vercel account

Okta has Authentication and User Management APIs that reduce development time with instant-on, scalable user infrastructure. Okta's intuitive API and expert support make it easy for developers to authenticate, manage and secure users and roles in any application.

Getting Started

To run this example, run the following commands:

git clone https://github.com/oktadev/okta-angular-microfrontend-example.git
cd okta-angular-microfrontend-example
npm ci

Create

…

View on GitHub

git clone https://github.com/oktadev/okta-angular-microfrontend-example.git
cd okta-angular-microfrontend-example
npm ci

Let's dive into the code! 🎉

We have an Angular project with two applications and one library inside the src/projects directory. The two applications are named shell and mfe-basket, and the library is named shared. The shell application is the micro-frontend host, and the mfe-basket is a micro-frontend remote application. The shared library contains code and application state we want to share across the site. When you apply the same sort of diagram shown above for this app, it looks like this:

In this project, we use the @angular-architects/module-federation dependency to help encapsulate some of the intricacies of configuring Webpack and the Module Federation plugin. The shell and mfe-basket application have their own separate webpack.config.js. Open the projects/shell/webpack.config.js file for either the shell or mfe-basket application to see the overall structure. This file is where we add in the wiring for the hosts, remotes, shared code, and shared dependencies in the Module Federation plugin. The structure will be different if you aren't using the @angular-architects/module-federation dependency, but the basic idea for configuration remains the same.

Let's explore the sections of this config file.

// ...imports here

const sharedMappings = new mf.SharedMappings();
sharedMappings.register(
  path.join(__dirname, '../../tsconfig.json'),
  [
    '@shared'
  ]);

module.exports = {
  // ...other very important config properties
  plugins: [
    new ModuleFederationPlugin({
      library: { type: "module" },

      // For remotes (please adjust)
      // name: "shell",
      // filename: "remoteEntry.js",
      // exposes: {
      //     './Component': './projects/shell/src/app/app.component.ts',
      // },        

      // For hosts (please adjust)
      remotes: {
        "mfeBasket": "http://localhost:4201/remoteEntry.js",
      },

      shared: share({
        // ...important external libraries to share

        ...sharedMappings.getDescriptors()
      })
    }),
    sharedMappings.getPlugin()
  ],
};

In the webpack.config.js for mfe-basket, you'll see the path for @shared at the top of the file and the configuration to identify what to expose in the remote application.

The shell application serves on port 4200, and the mfe-basket application serves on port 4201. We can open up two terminals to run each application, or we can use the following npm script created for us by the schematic to add @angular-architects/module-federation:

npm run run:all

When you do so, you'll see both applications open in your browser and how they fit together in the shell application running on port 4200. Click the Basket button to navigate to a new route that displays the BasketModule in the mfe-basket application. The sign-in button doesn't work quite yet, but we'll get it going here next.

Note - Another option I could have used for the starter is a Nx workspace. Nx has great tooling and built-in support for building micro frontends with Webpack and Module Federation. But I wanted to go minimalistic on the project tooling so you'd have a chance to dip your toes into some of the configuration requirements.

The @shared syntax might look a little unusual to you. You may have expected to see a relative path to the library. The @shared syntax is an alias for the library's path, which is defined in the project's tsconfig.json file. You don't have to do this. You can leave libraries using the relative path, but adding aliases makes your code look cleaner and helps ensure best practices for code architecture.

Because the host application doesn't know about the remote applications except in the webpack.config.js, we help out the TypeScript compiler by declaring the remote application in decl.d.ts. You can see all the configuration changes and source code made for the starter in this commit.

Add authentication using OpenID Connect

One of the most useful features of Module Federation is managing shared code and state. Let's see how this all works by adding authentication to the project. We'll use the authenticated state in the existing application and with a new micro frontend.

Use http://localhost:4200/login/callback for the Redirect URI and set the Logout Redirect URI to http://localhost:4200.

Okta application configuration:
Issuer:    https://dev-133337.okta.com/oauth2/default
Client ID: 0oab8eb55Kb9jdMIr5d6

NOTE: You can also use the Okta Admin Console to create your app. See Create an Angular App for more information.

Make a note of the Issuer and the Client ID. You'll need those values here soon.

We'll use the Okta Angular and Okta Auth JS libraries to connect our Angular application with Okta authentication. Add them to your project by running the following command.

npm install @okta/okta-angular@5.2 @okta/okta-auth-js@6.4

Next, we need to import the OktaAuthModule into the AppModule of the shell project and add the Okta configuration. Replace the placeholders in the code below with the Issuer and Client ID from earlier.

import { OKTA_CONFIG, OktaAuthModule } from '@okta/okta-angular';
import { OktaAuth } from '@okta/okta-auth-js';

const oktaAuth = new OktaAuth({
  issuer: 'https://{yourOktaDomain}/oauth2/default',
  clientId: '{yourClientID}',
  redirectUri: window.location.origin + '/login/callback',
  scopes: ['openid', 'profile', 'email']
});

@NgModule({
  ...
  imports: [
    ...,
    OktaAuthModule
  ],
  providers: [
    { provide: OKTA_CONFIG, useValue: { oktaAuth } }
  ],
  ...
})

After authenticating with Okta, we need to set up the login callback to finalize the sign-in process. Open app-routing.module.ts in the shell project and update the routes array as shown below.

import { OktaCallbackComponent } from '@okta/okta-angular';

const routes: Routes = [
  { path: '', component: ProductsComponent },
  { path: 'basket', loadChildren: () => import('mfeBasket/Module').then(m => m.BasketModule) },
  { path: 'login/callback', component: OktaCallbackComponent }
];

Now that we've configured Okta in the application, we can add the code to sign in and sign out. Open app.component.ts in the shell project. We will add the methods to sign in and sign out using the Okta libraries. We'll also update the two public variables to use the actual authenticated state. Update your code to match the code below.

import { Component, Inject } from '@angular/core';
import { filter, map, Observable, shareReplay } from 'rxjs';
import { OKTA_AUTH, OktaAuthStateService } from '@okta/okta-angular';
import { OktaAuth } from '@okta/okta-auth-js';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styles: []
})
export class AppComponent {
  public isAuthenticated$: Observable<boolean> = this.oktaStateService.authState$
      .pipe(
          filter(authState => !!authState),
          map(authState => authState.isAuthenticated ?? false),
          shareReplay()
      );

  public name$: Observable<string> = this.oktaStateService.authState$
      .pipe(
          filter(authState => !!authState && !!authState.isAuthenticated),
          map(authState => authState.idToken?.claims.name ?? '')
      );

  constructor(private oktaStateService: OktaAuthStateService, @Inject(OKTA_AUTH) private oktaAuth: OktaAuth) { }

  public async signIn(): Promise<void> {
    await this.oktaAuth.signInWithRedirect();
  }

  public async signOut(): Promise<void> {
    await this.oktaAuth.signOut();
  }
}

We need to add the click handlers for the sign-in and sign-out buttons. Open app.component.html in the shell project. Update the code for Sign In and Sign Out buttons as shown.

<li>
  <button *ngIf="(isAuthenticated$ | async) === false; else logout"
    class="flex items-center transition ease-in delay-150 duration-300 h-10 px-4 rounded-lg hover:border hover:border-sky-400"
    (click)="signIn()"
  >
    <span class="material-icons-outlined text-gray-500">login</span>
    <span>&nbsp;Sign In</span>
  </button>

    <ng-template #logout>
      <button 
        class="flex items-center transition ease-in delay-150 duration-300 h-10 px-4 rounded-lg hover:border hover:border-sky-400"
        (click)="signOut()"
      >
        <span class="material-icons-outlined text-gray-500">logout</span>
        <span>&nbsp;Sign Out</span>
      </button>
  </ng-template>
</li>

Try running the project using npm run run:all. Now you'll be able to sign in and sign out. And when you sign in, a new button for Profile shows up. Nothing happens when you click it, but we're going to create a new remote, connect it to the host, and share the authenticated state here next!

Create a new Angular application

Now you'll have a chance to see how a micro-frontend remote connects to the host by creating a micro-frontend app that shows the authenticated user's profile information. Stop serving the project and run the following command in the terminal to create a new Angular application in the project:

ng generate application mfe-profile --routing --style css --inline-style --skip-tests

With this Angular CLI command you

Generated a new application named mfe-profile, which includes a module and a component
Added a separate routing module to the application
Defined the CSS styles to be inline in the components
Skipped creating associated test files for the initial component

You'll now create a component for the default route, HomeComponent, and a module to house the micro frontend. We could wire up the micro frontend to only use a component instead of a module. In fact, a component will cover our needs for a profile view, but we'll use a module so you can see how each micro frontend can grow as the project evolves. Run the following two commands in the terminal:

ng generate component home --project mfe-profile
ng generate module profile --project mfe-profile --module app --routing --route profile

With these two Angular CLI commands you:

Created a new component, HomeComponent, in the mfe-profile application
Created a new module, ProfileModule, with routing and a default component, ProfileComponent. You also added the ProfileModule as a lazy-loaded route using the '/profile' path to the AppModule.

Let's update the code. First, we'll add the default route. Open projects/mfe-profile/src/app/app-routing.module.ts and add a new route for HomeComponent. Your route array should match the code below.

const routes: Routes = [
  { path: '', component: HomeComponent },
  { path: 'profile', loadChildren: () => import('./profile/profile.module').then(m => m.ProfileModule) }
];

Next, we'll update the AppComponent and HomeComponent templates. Open projects/mfe-profile/src/app/app.component.html and delete all the code in there. Replace it with the following:

<h1>Hey there! You're viewing the Profile MFE project! 🎉</h1>

<router-outlet></router-outlet>

Open projects/mfe-profile/src/app/home/home.component.html and replace all the code in the file with:

<p>
  There's nothing to see here. 👀 <br/>
  The MFE is this way ➡️ <a routerLink="/profile">Profile</a>
</p>

Finally, we can update the code for the profile. Luckily, Angular CLI took care of a lot of the scaffolding for us. So we just need to update the component's TypeScript file and the template.

Open projects/mfe-profile/src/app/profile/profile.component.ts and edit the component to add the two public properties and include the OktaAuthStateService in the constructor:

import { Component, OnInit } from '@angular/core';
import { OktaAuthStateService } from '@okta/okta-angular';
import { filter, map } from 'rxjs';

@Component({
  selector: 'app-profile',
  templateUrl: './profile.component.html',
  styles: []
})
export class ProfileComponent {
  public profile$ = this.oktaStateService.authState$.pipe(
    filter(state => !!state && !!state.isAuthenticated),
    map(state => state.idToken?.claims)
  );

  public date$ = this.oktaStateService.authState$.pipe(
    filter(state => !!state && !!state.isAuthenticated),
    map(state => (state.idToken?.claims.auth_time as number) * 1000),
    map(epochTime => new Date(epochTime)),
  );

  constructor(private oktaStateService: OktaAuthStateService) { }
}

Next, open the corresponding template file and replace the existing code with the following:

<h3 class="text-xl mb-6">Your Profile</h3>

<div *ngIf="profile$ | async as profile">
  <p>Name: <span class="font-semibold">{{profile.name}}</span></p>
  <p class="my-3">Email: <span class="font-semibold">{{profile.email}}</span></p>
  <p>Last signed in at <span class="font-semibold">{{date$ | async | date:'full'}}</span></p>
</div>

Try running the mfe-profile app by itself by running ng serve mfe-profile --open in the terminal. Notice when we navigate to the /profile route, we see a console error. We added Okta into the shell application, but now we need to turn the mfe-profile application into a micro frontend and share the authenticated state. Stop serving the application so we're ready for the next step.

Module Federation for your Angular application

We want to use the schematic from @angular-architects/module-federation to turn the mfe-profile application into a micro frontend and add the necessary configuration. We'll use port 4202 for this application. Add the schematic by running the following command in the terminal:

ng add @angular-architects/module-federation --project mfe-profile --port 4202

This schematic does the following:

Updates the project's angular.json config file to add the port for the application and updates the builder to use a custom Webpack builder
Creates the webpack.config.js files and scaffolds out default configuration for Module Federation

First, let's add the new micro frontend to the shell application by updating the configuration in projects/mfe-profile/webpack.config.js. In the middle of the file, there's a property for plugins with commented-out code. We need to finish configuring that. Since this application is a remote, we'll update the snippet of code under the comment:

// For remotes (please adjust)

The defaults are mostly correct, except we have a module, not a component that we want to expose. If you want to expose a component instead, all you'd do is update which component to expose. Update the configuration snippet to expose the ProfileModule by matching the following code snippet:

// For remotes (please adjust)
name: "mfeProfile",
filename: "remoteEntry.js",
exposes: {
  './Module': './projects/mfe-profile/src/app/profile/profile.module.ts',
},

Now we can incorporate the micro frontend in the shell application. Open projects/shell/webpack.config.js. Here is where you'll add the new micro frontend so that the shell application knows how to access it. In the middle of the file, inside the plugins array, there's a property for remotes. The micro frontend in the starter code, mfeBasket, is already added to the remotes object. You'll also add the remote for mfeProfile there, following the same pattern but replacing the port to 4202. Update your configuration to look like this.

// For hosts (please adjust)
remotes: {
  "mfeBasket": "http://localhost:4201/remoteEntry.js",
  "mfeProfile": "http://localhost:4202/remoteEntry.js"
},

We can update the code to incorporate the profile's micro frontend. Open projects/shell/src/app/app-routing.module.ts. Add a path to the profile micro frontend in the routes array using the path 'profile'. Your routes array should look like this.

const routes: Routes = [
  { path: '', component: ProductsComponent },
  { path: 'basket', loadChildren: () => import('mfeBasket/Module').then(m => m.BasketModule) },
  { path: 'profile', loadChildren: () => import('mfeProfile/Module').then(m => m.ProfileModule)},
  { path: 'login/callback', component: OktaCallbackComponent }
];

What's this!? The IDE flags the import path as an error! The shell application code doesn't know about the Profile module, and TypeScript needs a little help. Open projects/shell/src/decl.d.ts and add the following line of code.

declare module 'mfeProfile/Module';

The IDE should be happier now. 😀

Next, update the navigation button for Profile in the shell application to route to the correct path. Open projects/shell/src/app/app.component.html and find the routerLink for the Profile button. It should be approximately on line 38. Currently the routerLink configuration is routerLink="/", but it should now be

<a routerLink="/profile">

This is everything we need to do to connect the micro-frontend remote to the host application, but we also want to share authenticated state. Module Federation makes sharing state a piece of (cup)cake.

Micro-frontend state management

To share a library, you need to configure the library in the webpack.config.js. Let's start with shell. Open projects/shell/src/webpack.config.js.

There are two places to add shared code. One place is for code implementation within the project, and one is for shared external libraries. In this case, we can share the Okta external libraries as we didn't implement a service that wraps Okta's auth libraries, but I will point out both places.

First, we'll add the Okta libraries. Scroll down towards the bottom of the file to the shared property. You'll follow the same pattern as the @angular libraries already in the list and add the singleton instances of the two Okta libraries as shown in this snippet:

shared: share({
  // other Angular libraries remain in the config. This is just a snippet
  "@angular/router": { singleton: true, strictVersion: true, requiredVersion: 'auto' },
  "@okta/okta-angular": { singleton: true, strictVersion: true, requiredVersion: 'auto' },
  "@okta/okta-auth-js": { singleton: true, strictVersion: true, requiredVersion: 'auto' },

  ...sharedMappings.getDescriptors()
})

When you create a library within this project, like the basket service and project service in the starter code, you add the library to the sharedMappings array at the top of the webpack.config.js file. If you create a new library to wrap Okta's libraries, this is where you'd add it.

Now that you've added the Okta libraries to the micro-frontend host, you need to also add them to the remotes that consume the dependencies. In our case, only the mfe-profile application uses Okta authenticated state information. Open projects/mfe-profile/webpack.config.js. Add the two Okta libraries to the shared property as you did for the shell application.

Now, you should be able to run the project using npm run run:all, and the cupcake storefront should allow you to log in, see your profile, log out, and add items to your cupcake basket!

Next steps

I hope you enjoyed this first post on creating an Angular micro-frontend site. We explored the capabilities of micro frontends and shared state between micro frontends using Webpack's Module Federation in Angular. You can check out the completed code for this post in the local branch in the @oktadev/okta-angular-microfrontend-example GitHub repo by using the following command:

git clone --branch local https://github.com/oktadev/okta-angular-microfrontend-example.git

Stay tuned for part two. I'll show how to prepare for deployment by transitioning to dynamic module loading and deploying the site to a free cloud provider.

Learn about Angular, OpenID Connect, micro frontends, and more

Can't wait to learn more? If you liked this post, check out the following.

Don't forget to follow us on Twitter and subscribe to our YouTube channel for more exciting content. We also want to hear from you about what tutorials you want to see. Leave us a comment below.

Animating Your Angular App

Alisa — Tue, 05 Apr 2022 18:14:53 +0000

Angular has built-in support for adding animations. In this talk, you'll learn how to add some sparkle to your Angular app by harnessing the power of Angular’s animation library. We’ll start from the basics of state and triggers, use built-in fancy effects, add routing animations, and cover how to make your animations reusable and scalable in this hands-on walk-through.

This video is ideal for those who have some basic CSS and Angular knowledge. The animations we'll add are straightforward so that we can focus on the capabilities of the Angular animation library.

Animation code

You can check out the starting code for the app.

alisaduncan / angular-hero-animations

Sample app and code for animating the Heroes contact list app for a talk on Angular Animations

You can see the finished app with animations in the animations branch of the repo.

This presentation was prepared for Front Stage. Unfortunately, the conference was canceled due to the ongoing conflicts in Ukraine, where the conference organization is based. 🇺🇦 This talk was also presented at International Women's Day San Jose and AngularKC Meetup in March 2022.

Forem: Alisa

A Quick Vibe Code Experiment with Angular's MCP Server

Angular's MCP server

Set up the MCP server connection

Use AI to check AI?

Add LLM prompts to Angular projects

Vibe code with the Angular MCP server

Control agent behavior using custom instructions

The AGENTS.md file is AI-platform agnostic

Create organization-specific instructions applicable across technology stacks

Provide different sets of instructions within monorepo projects

Create AI agent instructions file for your Angular project

Can AI keep up with modern Angular features?

Lean into signals using AI

alisaduncan / todo-mcp-experiment

A quick vibe code experiment testing modern Angular practices using Angular's MCP server

Use the Angular MCP server along with Agent instructions for the best output

Add Step-up Authentication Using Angular and NestJS

Use Step Up Authentication Challenge to protect resources

Prepare the Angular and NestJS web application

oktadev / okta-angular-nestjs-stepup-auth-example

Example project demonstrating step-up auth implementation in Angular and NestJS

Add Step-up Authentication Using Angular and NestJS Example

Getting Started

Create an OIDC Application

Set up the Identity Provider to use OAuth 2.0 and OpenID Connect

Step-up authentication mechanics at a glance

Set up authenticators

Guard a route with step-up authentication

Protect API resources with step-up authentication challenge

Check the access token's ACR claim in a NestJS middleware

Use an Angular interceptor to catch step-up HTTP error responses

Handle step-up errors when making HTTP calls in Angular

Ensure authentication recency in step-up authentication

Step-up authentication in Angular and NestJS applications

Flexible Authentication Configurations in Angular Applications Using Okta

Configuring authentication properties using Okta in Angular applications

Scaffold an Angular standalone application

Create an Okta OAuth 2.0 and OpenID Connect SPA client

Use the Okta Angular SDK for authentication

Display OpenID Connect claims

Intercept HTTP requests to add the Authorization header with a functional interceptor

Add runtime authentication configuration to an Okta Angular app

Use OAuth 2.0, OpenID Connect, and the Okta Angular SDK for secure authentication

oktadev / okta-angular-standalone-runtime-config-example

Use Okta Angular SDK for runtime configuration loading in standalone Angular applications

Angular Standalone Runtime Configuration Example

Getting Started

Create an OIDC Application in Okta

How Authentication and Authorization Work for SPAs

Authentication and Authorization using OAuth 2.0 + OpenID Connect (OIDC)

OAuth 2.0 + OIDC for JavaScript clients and SPA

Auth tokens in OAuth 2.0 + OIDC

ID token

Access token

Refresh token

Create an OAuth 2.0 + OIDC Compliant Authorization server

View the well-known endpoint for OIDC Discovery

Debug the authorization code and token requests

Add authentication to your SPA

Use auth tokens in SPAs

How to use the access token

okta / samples-nodejs-express-4

Express 4 samples. Will publish an artifact that can be consumed by end-to-end sample repos

Express Sample Applications for Okta

Configuration

How to use the ID token

Learn more about OAuth, OIDC, tokens, and authentication best practices

A Practical Guide to Providers in Angular

Quick overview of Dependency Injection

Angular’s Dependency Injection system

The Injector

Providing to different injectors

Injection tokens in Angular

Configuring providers in Angular’s Dependency Injection system

Configure providers with useClass

Configure providers with useExisting

Configure with useValue

Configure with useFactory

Learn more about Angular Dependency Injection

The `AGENTS.md` file is AI-platform agnostic

The `Injector`

Configure providers with `useClass`

Configure providers with `useExisting`

Configure with `useValue`

Configure with `useFactory`