Thursday, December 22, 2016

Angular Material Beta Release, New Flex-Layout library

We're sneaking in a little holiday gift at the end of the year: two new beta releases for developers to try out with the latest version of Angular.

material components with a custom theme and RTL text

In March, we gave you a first preview of the new Angular Material components. Today's beta release of @angular/material includes 22 UI components written for the latest Angular: button, button‑toggle, card‑list, chips, checkbox, dialog, grid‑list, icon, input, menu, progress‑bar, progress‑spinnerradio‑buttonselectsidenavslide‑toggleslidersnackbartextareatoolbar, and tooltip. It also provides support for accessibility, custom themes, and RTL text.  For documentation and examples, see

Also out in beta today, the new @angular/flex-layout package is a general-purpose flex-based layout library for use in any Angular application later than version 2.4. It provides a responsive engine and API to easily define how UI layouts should update as viewport sizes change with orientation across different display devices. The HTML API makes it trivial to quickly arrange (and auto-resize) web page component layouts. In Angular 1.x, layout tools were included as part of Angular Material. With flex-layout, we have made layout a standalone library, decoupled from the UI components. Learn more about the flex-layout beta here.

Whether you're building a new app, or upgrading from a legacy Angular 1.x app that needs Layout and Angular Material APIs, these components will help you to quickly build a beautiful and performant UI consistent with Google's Material Design spec.

What does beta mean?

We've built all of the core UI components that most applications will need. Start using these libraries, and give us feedback on GitHub.

We don’t plan to make any large API changes before exiting beta, however we’ll make changes based on feedback we receive during the beta process.

What's still in the works?

For Angular Material, developers can expect other advanced components (e.g. data-table, date-picker), and typography support. Both libraries will see ongoing bug fixes and feature improvements.
For users on Angular Material 1.x, a new release is expected in early 2017 with bug fixes and security improvements.

Tuesday, December 20, 2016

Angular 2.4.0 Now Available

Angular version 2.4.0 - stability-interjection - is now available. This is a minor release following our announced adoption of Semantic Versioning, meaning that it contains no breaking changes and that it is a drop-in replacement for 2.x.x.

What's new?
    • This release updates our dependencies to the recently announced RxJS 5 stable

For the complete list of features and bugfixes please see the changelog.

Tuesday, December 13, 2016

Ok... let me explain: it's going to be Angular 4.0, or just Angular

This is a guest blog post by Juri Strumpflohner. Juri is a full-stack developer, architect and tech lead with a passion for frontend development, especially Angular. Juri writes technical articles on his personal blog and is the author of some online video courses. He also likes to engage and help the Angular community on Twitter, so follow him for more interesting news and articles around Angular and frontend web development. Juri was an attendee of NG-BE, Belgium’s first Angular conference last week and did a better job covering our announcements than we would have done, so we are cross-posting his blog post here.

Update: This blog was updated by the Angular team on 2017-01-26 to reflect the latest naming standards.

At the 8th and 9th of December 2016 was NG-BE, Belgium’s first Angular conference. Igor Minar (Angular lead dev) attended as the keynote speaker with some interesting announcements regarding Angular’s release schedule. Please read the entire post, there are a couple of important things.
Igor was extremely open and transparent about the announcement and even about the way of presenting it. He basically created the presentation openly the day before the conference:

So here it is:

Angular 4, March 2017, Backwards Compatible w/ Angular 2

Why Angular 4?? Why even Angular 3?? What is going on?

Angular uses SEMVER

Back in September when the new Angular was finally released, the Angular team also announced they will switch to Semantic Versioning (SEMVER).
As the name already explains, Semantic Versioning is all about adding meaning to version numbers. This allows developers to not only reason about any upgrade we do, but we can even let tools such as NPM do it in a automatic and safe manner for us.
A semantic version consists of three numbers:

2.3.1 - major = breaking change, minor = new features, not breaking, patch = bugfixes, not breaking

Whenever you fix a bug and release it, you increase the last number, if a new feature is added, you increase the second number and whenever you release a breaking change you increase the first number.
“A breaking change happens whenever you as a developer and consumer of a library, have to step in and adjust your code after a version upgrade.”
So what does this mean for the Angular team? As with every evolving piece of software, breaking changes will occur at some point. For example, giving a compiler error for existing application bugs that went unnoticed with the previous compiler version, anything, that will break an existing application when upgrading Angular, requires the team to bump the major version number.
Just to be clear, as also Igor mentioned in his talk. Right now, even just upgrading Angular’s TypeScript dependency from v1.8 to v2.1 or v2.2 and compile Angular with it, would technically cause a breaking change. So they’re taking SEMVER very, very seriously.

Breaking changes don’t have to be painful!

People that have been following the Angular community for a while, definitely know what I’m talking about. We went from Angular 1 to Angular 2, and it was a total breaking change, with new APIs, new patterns. That was obvious: ultimately Angular 2 was a complete rewrite. (Even though there are upgrade options for you available)
Changing from version 2 to version 4, 5, … won’t be like changing from Angular 1. It won’t be a complete rewrite, it will simply be a change in some core libraries that demand a major SEMVER version change. Also, there will be proper deprecation phases to allow developers to adjust their code.
Internally at Google, the Angular team uses a tool for handling automatic upgrades, even of breaking changes. This is still something that has to be planned in more detail, but the team is working hard on making this tool generally available, most probably in 2017 in time for version 5.

It’s just “Angular”

As you might have already guessed, the term “Angular 2” is also kind of deprecated once we get to version 4, 5 etc. That said, we should start naming it simply “Angular” without the version suffix.
“It’s just #angular”
Also, we should start avoiding GitHub/NPM libraries prefixed with ng2- or angular2-.

Naming guidelines

Basically from now on, you should name versions 2.0.0 or later of Angular simply “Angular”. Try to avoid using the version number, unless it is really necessary to disambiguate.

Three simple guidelines:
  • Use “Angular” for versions 2.0.0 and later (e.g. “I’m an Angular developer”, “This is an Angular meetup”, “The Angular ecosystem is growing quickly”)
  • Use "AngularJS" to describe versions 1.x or earlier
  • Use the version number “Angular 4.0” "Angular 2.4" when needed to talk about a specific release (e.g. when talking about a newly introduced feature - “This is an introduction to feature X, introduced in Angular 4”, “I’m proposing this change for Angular 5”)
  • Use full semver version when reporting a bug (e.g. “This issue is present as of Angular 2.3.1”)
All the docs - even for AngularJS - will be aligned to this in the coming weeks. Also in blog articles, courses, books, if you are targeting a very specific version of Angular for a reason, consider adding a header line which states that:
“This article uses Angular v2.3.1.”
That helps avoid confusion for your readers, especially when you are writing about specific APIs.

Why not version 3 then?

The core Angular libraries live in one single GitHub repository at All of them are versioned the same way, but distributed as different NPM packages:

@angular/core v2.3.0, @angular/compiler v2.3.0, @angular/compiler-cli v2.3.0, @angular/http v2.3.0, in bold: @angular/router v3.3.0

Due to this misalignment of the router package’s version, the team decided to go straight for Angular v4. In this way again, all the core packages are aligned which will be easier to maintain and help avoid confusion in the future.
Also it is important to understand how Angular is being used and integrated inside Google (Igor speaks about this here in his keynote). All Google applications use Angular version equal to the current GitHub’s master branch of the Angular repository. Whenever a new commit lands in master, it will be integrated into Google’s single, giant mono-repo, where also other products such as Maps, Adsense etc. live. As a consequence all of the projects using Angular internally at Google will run their extensive test suites against this new version. This makes the team very confident to cut a new release, since it will contain the exact combination of versions of Angular packages that have been already battle tested inside Google. Thus, having aligned versions totally makes sense and makes it easier to maintain them over time, which in turn helps the team be more productive in releasing new features.

Tentative release schedule

The fact that breaking changes will arrive, doesn’t mean they will arrive every other week. The Angular team committed to time based releases that occur in three cycles:
  • patch releases every week,
  • 3 monthly minor release after each major release and
  • a major release with easy-to-migrate-over breaking changes every 6 months.
The next 3 months will be dedicated to finalizing Angular 4.0.0.

Weekly breakdown of all releases starting with 4.0.0-beta.0, ending with 4.0.0 on March 1, 2017

After Angular 4.0.0, this will be the tentative schedule for further releases:

Version 4 in March 2017, Version 5 in September/October 2017, Version 6 in March 2018, Version 7 in September/October 2018

Video: See the announcement yourself


There are two main important messages here:
  • don’t worry about version numbers
  • we do need to evolve Angular in order to avoid another Angular 1 to Angular 2 change, but we should do it together as a community in a transparent, predictable and incremental way.
Also, I’d like to thank Igor for being so open at presenting this data, especially since he knows what a sensitive topic breaking changes are and have been in the past. This means a lot and I hope that the community will realize why all these changes are good for everyone involved.

Thursday, December 8, 2016

Angular 1.6.0 released

AngularJS 1.6.0 - rainbow-tsunami

Release Announcement

Continuing our development and support of Angular 1, we are announcing the next significant release, 1.6.0, which has been in development since May this year.

In this release we have added a number of useful features that should improve the developer experience and we have tightened up the security of Angular 1 even further. We have also removed a handful of deprecated features that makes the codebase easier to maintain and in many cases improves performance.

New Features

Here are the most significant new features available in 1.6.0. Check out the changelog for more detail.

Inheriting ngModelOptions

When defining model options using the ngModelOptions directive, you can now choose to inherit options from ancestor ngModelOptions directives. This means that developers can centralise common model options rather than repeating themselves across all their HTML.

You can see examples of what you can do with this new feature in Todd Motto's recent blog post.

Alignment with jQuery 3

jQuery 3 was released in June this year and contains some changes that left our own jqLite implementation out of sync. In this release we have changed jqLite so that it matches the behaviour of jQuery 3.

Controller binding pre-assignment

We no longer pre-assign bindings onto instances of directive controllers before calling their constructors. This behaviour was not in keeping with how JavaScript object instantiation works and also prevented developers from using native JavaScript classes where available.

Now all directive controllers should use $onInit to initialize their state, where the bindings are guaranteed to be ready. This is also closer to the semantic of Angular 2 components.

Todd Motto has written about how to handle this change in a recent blog post.

Support for non-string select options

With improved support for non-string values in option elements, you can now render most select option use cases using ngRepeat and ngValue, rather than having to resort to ngOptions.

In other words, as shown in this Plunker, rather than this:

  ng-options="x as disable when !x.enabled for x in $ctrl.options">
  <option value="">Empty Option</option>

you can now write:

<select ng-model="$ctrl.value">
  <option ng-value="null">Empty Option</option>
    ng-repeat="x in $ctrl.options"

This results in clearer Angular 1 templates and is more in keeping with how it is done in Angular 2.

Better support for range inputs

In Angular 1.5.x (from 1.5.10 and later) you need to manually opt-in to this support since the behaviour of native range inputs required a change to how ngModel handled updates to the value:

Angular 1.6 now fully supports <input type=range ng-model="..."> by default without having to opt-in.

  • It requires the model to be a number, and will set the model to a number.
  • It only supports setting minimum and maximum values via the min/max attributes.
  • It follows the browser behavior of never allowing an invalid value: when the browser converts an invalid value to a valid value, the the model is set to this new valid value.

Security Improvements

There have been a number of commits that have improved or clarified the security of Angular 1 applications. Here are some of the highlights.

Mozilla Addons

Due to some strengthening work we have done to make it more difficult to autobootstrap Angular in browser extensions, all versions of Angular from 1.5.9/1.6.0 onwards are now whitelisted as safe to use in Mozilla Addons.

Expression sandbox removal

In this version of Angular we have removed the Angular expression sandbox feature. Some developers were incorrectly using this in an attempt to prevent XSS attacks to their templates. To make it clear that this should not be relied upon in this way we have made the decision to remove it completely. A more detailed write up of the background, the decision and whether you need to do anything can be found in our previous blog post.


JSONP is now secured by the $sce service, in the same way that other significant resources are in Angular 1. JSONP URLs must now be whitelisted or explicitly trusted before Angular will allow a request to the end point. Further the syntax for JSONP URLs is now more secure, by disallowing the JSON_CALLBACK from the URL template and requiring that the callback is provided via the jsonpCallbackParam config param for requests.

Other Changes

There are over 70 significant commits between 1.5 and 1.6. You can find a detailed list of all the changes, including bug fixes and performance improvements in our changelog.

Migrating from 1.5 to 1.6

While there are a number of breaking changes between 1.5 and 1.6, many only affect very rare corner cases. There are a few significant changes that you should be aware of and we have a comprehensive migration guide to ensure that your migration goes smoothly.

Previous Version Support

We believe that Angular 1.6 is now the best Angular 1 version out there and that you should update your applications to use it.

We continue to support Angular 1.2 with security patches as it is the last version of Angular to support Internet Explorer 8 and from now on Angular 1.5 will receive serious bug fixes and security patches.

Angular 1.6 will get regular non-breaking change releases over the next six months, and we will be aiming for the release of Angular 1.7 containing any necessary breaking changes by Summer 2017.

Thank you

As always the work on Angular 1 is a major collaborative effort between people both within and outside the Angular team. We hope that it continues to provide the solid application development platform that you have been relying on for over 7 years!

Angular 2.3.0 Now Available

Angular version 2.3.0 - is now available. This is a minor release following our announced adoption of Semantic Versioning, meaning that it contains no breaking changes and that it is be a drop-in replacement for 2.x.x. This is the final minor release for 2.x.

What's new?
  • We're now releasing the first version of the Angular Language Service. This is a service that is designed to integrate with IDEs and provide error checking and type completion within Angular Templates. We've built this service independent of editor, but we will soon be releasing an initial set of bindings for VS Code.
  • Developers can now take advantage of object inheritance for components. Share or simplify component functionality by inheriting from a parent component.
  • The latest release of zone.js includes improved stack traces. You should see stack traces that are shorter and are zone-aware:
    • 2.2.x Stack Trace:
      Error.spec.js:53 Error: Inside at ZoneAwareError (zone.js:652) at insideRun (Error.spec.js:31) at ZoneDelegate.invoke (zone.js:216) at (zone.js:100) at testFn (Error.spec.js:29) at ZoneDelegate.invoke (zone.js:216) at (zone.js:100) at Object.eval (Error.spec.js:19)
    • 2.3.0 Stack Trace:
      Error.spec.js:54 Error: Inside [InnerZone] at insideRun (Error.spec.js:31) [InnerZone] at (zone.js:100) [<root> => InnerZone] at testFn (Error.spec.js:29) [<root>] at (zone.js:100) [ProxyZone => <root>] at Object.eval (Error.spec.js:19) [ProxyZone]

For the complete list of features and bugfixes please see the changelog.

Monday, November 14, 2016

Angular 2.2.0 Now Available

Angular version 2.2.0 - is now available. This is a minor release following our announced adoption of Semantic Versioning, meaning that it contains no breaking changes and that it is be a drop-in replacement for 2.1.x.

What's new?
  • You can now AOT compile your Angular 2 Components and Modules when using @angular/upgrade. Check out the upgrade guide on our docs site.
  • We've added features to the router to assist with version 1.x to 2.x migrations.
  • Code generated from AOT compilation (NgFactories) will now be smaller in cases with large numbers of forms. We will continue to improve the size of generated code over time.
  • We've added guides on using Angular with ES5 and ES6/7.

For the complete list of features and bugfixes please see the changelog.

Wednesday, November 2, 2016

Easy Angular Authentication with JSON Web Tokens

Easy Angular Authentication with JSON Web Tokens

Stateless authentication is a great fit for Angular apps. In this post, guest-blogger Ryan Chenkie from Auth0 talks about implementing it using JSON Web Tokens. -- Victor Savkin

TL;DR: Single page apps--like the ones we build with Angular--present a few challenges when it comes to authentication. In general, traditional session-based authentication isn't a good fit for SPAs that use data APIs because it necessitates state on the server. A better way to do authentication in Angular apps (and SPAs in general) is with JSON Web Tokens (JWTs). Read on to find out more about JWTs, or check out Angular 2 Tour of Secret Heroes to see an example of a full Angular 2 app with user authentication.
Pretty well all non-trivial applications require some way of dealing with user authentication and authorization. This can be fairly straight-forward in round-trip applications because all that is really needed when a user logs in is to check their credentials against a database, save a session for them on the server, and return a cookie to be saved in their browser. The cookie is then sent along in subsequent requests to the server and is checked against the session to verify their identity.
This works well for "traditional" applications, but it isn't a great fit for single page apps that use data APIs. Since SPAs are client-side apps, dealing with the notion of the user's authentication state is also a bit trickier. Essentially what it boils down to is that we need some indication of the user's authentication state even though the backends that we rely on should remain stateless. This isn't a problem in round-trip apps because the HTML and data that get returned to the user is constructed on the backend, which is exactly the place that a stateful check can be done to figure out whether or not the user is currently logged in. When we use REST APIs for data however, a stateful session that tracks authentication is bad practice.

JSON Web Tokens - Stateless Authentication in Angular Apps

A great way to do stateless authentication in an Angular app is to use JSON Web Tokens (JWT). JWT is an open standard (RFC 7519), and likely the most compelling reason to choose it as an authentication mechanism is that it can be used to transmit arbitrary data as a JSON object. Since JWTs are digitally signed with a secret key that lives only on the server, we can rest assured that the information in the token can't be tampered with at any point. If the payload in the JWT were to be tampered with, the token would become invalid, which means it wouldn't be able to get past any checkpoints on the server. This makes JWT the perfect mechanism for transmitting information about a user and it gives us a distinct advantage: we can include everything required for our API to know who the user is and what level of access they should have, and the API doesn't need to know a single thing about them prior to the JWT arriving.
So what does a JWT look like? Here's an example:
JWTs contain three parts, and each of them is tacked together with a dot separator. The three parts are:


Where we define the algorithm used to sign the token, as well as the token type.


The meat of the JWT. This is where we keep a JSON object of all the claims we want. Claims can include those that are registered in the JWT spec, as well as any arbitrary data we want.


The signature is where the signing action happens. To get the signature, we take the Base64URL encoded header, tack the Base64URL encoded payload next to it, and run that string along with the secret key through the hashing algorithm we've chosen. For the token to properly decode on the backend, it needs to have exactly this form, which means that if someone tries to change any of the information contained within, they'll be out of luck.
We can see this token decoded with Auth0's open source JWT debugger.
angular jwt authentication
It should be noted that although JWTs are digitally signed, they are not encrypted. While the digital signature ensures that the content of a JWT cannot be tampered with, they should not be used to transmit sensitive information, as the payload can easily be decoded with tools like the debugger.

How Are JWTs Used to Authenticate Angular Apps?

For Angular apps that use data APIs, the typical scenario is this:
  1. Users send their credentials to the server which are verified against a database. If everything checks out, a JWT is sent back to them.
  2. The JWT is saved in the user's browser somehow--either by holding it in local storage or in a cookie.
  3. The presence of a JWT saved in the browser is used as an indicator that a user is currently logged in.
  4. The JWT's expiry time is continually checked to maintain an "authenticated" state in the Angular app, and the user's details are read from the payload to populate views such as the their profile.
  5. Access to protected client-side routes (such as the profile area) are limited to only authenticated users
  6. When the user makes XHR requests to the API for protected resources, the JWT gets sent as an Authorization header using the Bearer scheme, or as a cookie.
  7. Middleware on the server--which is configured with the app's secret key--checks the incoming JWT for validity and, if valid, returns the requested resources.
Fortunately for us, there are several open source libraries for both Angular 1.x and 2 which help us work with JWTs. These libraries are varied in their functionality, but some of the features we get with them are the ability to:
  • Decode the JWT and read its payload
  • Attach the JWT as an Authorization header to XHR requests
  • Have a service which exposes methods for logging in and logging out, and which checks whether the current user's JWT is expired or not

Angular 1.x

Angular 2

There are also hosted authentication solutions that can drastically simplify the process of setting up user login and signup functionality for Angular apps. This basically means that we don't need to worry about any logic for checking the user's credentials and signing tokens for them.

Authentication in Action

So we've got a list of things that our Angular apps should be doing to deal with authentication, but what does this look like in practice? Let's see an example using Angular 2.

Retrieve a JWT for a User and Save it in Local Storage

To retrieve a JWT for a user, we need to verify their credentials against a database. If everything checks out, we sign a JWT and send it back to them in the response. We can use almost any server-side language or framework for this task, and there are JWT libraries available for almost everything.
With the token signing logic set up, we need to expose an endpoint that the app can make a request to for authentication. For this, we just need to send a regular HTTP request. Placing this logic in an injectable service gives us a way to reuse it across our application.
// auth.service.ts

import { Injectable } from '@angular/core';
import { Http } from '@angular/http';
import 'rxjs/add/operator/map';

export class AuthService {

  constructor(private http: Http) {}

  login(credentials) {'', credentials)
      .map(res => res.json())
        // We're assuming the response will be an object
        // with the JWT on an id_token key
        data => localStorage.setItem('id_token', data.id_token),
        error => console.log(error)
We can then wire up a form which takes input from the user and calls the AuthService.
// login.component.ts

import { Component } from '@angular/core';
import { AuthService } from './auth.service';

interface Credentials {
  username: string,
  password: string

  selector: 'login',
  template: `
    <form #f="ngForm" (ngSubmit)="onLogin(f.value)" *ngIf="!auth.loggedIn()">
      <input type="text" placeholder="username" ngControl="username">
      <input type="password" placeholder="password" ngControl="password">
      <button type="submit">Submit</button>    

export class LoginComponent {

  credentials: Credentials;

  constructor(private auth: AuthService) {}

  onLogin(credentials) {
With the login form and the authentication service in place, the user's JWT will be saved in local storage if they successfully authenticate.
You can see that we've got an *ngIf condition on the form which is looking for a loggedIn method on the AuthService. Let's put that in next.

Checking for an Unexpired Token

With stateless authentication, the only real indication for the front end that the user is "authenticated" is if they have an unexpired JWT. Certainly a more robust indication would be a check to make sure their JWT is not only unexpired, but is also still valid. However, to do this kind of check, the front end would need to know the secret key used to sign the JWT, and we really don't want to expose that. Simply checking the expiry is just fine though; if the token is invalid (in other ways than it just being expired), it won't be useful for retrieving protected API resources anyway.
To do this kind of check, we can get some help from angular2-jwt's tokenNotExpired function.
npm install angular2-jwt
// auth.service.ts

import { tokenNotExpired } from 'angular2-jwt';


loggedIn() {
  return tokenNotExpired();

This function simply checks the expiry date of the JWT and returns true if it is not expired.

Limit Routes to Authenticated Users

We've got a way to hide our links and navigation elements if the user either doesn't have a JWT or if their JWT is expired. However, they could still navigate by plugging in URI segments manually, so what we need is a way to limit navigation to private routes altogether. To do this we can set up an AuthGuard which checks whether the user has an unexpired JWT in local storage. We'll then apply the guard through CanActivate when we set up the routing configuration.
// auth-guard.service.ts

import { Injectable } from '@angular/core';
import { Router } from '@angular/router';
import { CanActivate } from '@angular/router';
import { Auth } from './auth.service';

export class AuthGuard implements CanActivate {

  constructor(private auth: Auth, private router: Router) {}

  canActivate() {
    if(this.auth.loggedIn()) {
      return true;
    } else {
      return false;
When route navigation is requested, AuthGuard will use the AuthService to check for the presence of an unexpired JWT and, if one exists, the user will be allowed to continue to the route. If the user isn't authenticated however, they will be navigated to an "unauthorized" page.
The AuthGuard needs to be applied to whichever routes should be kept private, and this is done in the RouterConfig setup.

import { AuthGuard } from './auth-guard.service';

export const routes: RouterConfig = [
  { path: 'admin', component: AdminComponent, canActivate: [AuthGuard] },
  { path: 'unauthorized', component: UnauthorizedComponent }


Send Authenticated HTTP Requests

The last big step for applying authentication to our app is to have the user's JWT sent as an Authorization header in the HTTP requests they make. Since Angular 2 doesn't have any concept of HTTP interceptors like Angular 1.x does, we need to either send the header in the options object of each request, or we can wrap Http to perform this automatically. The angular2-jwt library provides AuthHttp which does the latter.
// secure-stuff.component.ts

import { Component } from '@angular/core';
import { AuthHttp, tokenNotExpired } from 'angular2-jwt';
import 'rxjs/add/operator/map';

  selector: 'secure-stuff',
  template: `
    <button (click)="getSecureStuff()">Get Secure Stuff!</button>

export class SecureStuffComponent {

  stuff: [];

  constructor(private authHttp: AuthHttp) {}

  getSecureStuff() {
      .map(res => res.json())
        data =>  this.stuff = data.stuff,
        error => console.log(error)
Note: Any application that uses JWT authentication should always be served over HTTPS to prevent malicious interception of the token.

Log the User Out

With stateless authentication using JWTs, logging the user out is just a matter of removing their token from local storage.
// auth.service.ts


export class AuthService {


  logout() {
You might be wondering if this is secure or not, given the fact that we're just removing the token from its holding place and it could, in reality, still be used to access the API. We've got two options to address this concern: we can set the token's expiry time to be short and/or we can implement token blacklisting on the server. With a short window of validity, the JWT can't be exploited for very long, and with blacklisting, the token's ability to access secure resources can be revoked altogether.

Full Example: Angular 2 Tour of Secret Heroes

It would be nice to see all of this authentication business in action in a working app. For that, I've put together a fork of John Papa's Tour of Heroes app (used in the Angular 2 Getting Started guide), called Angular 2 Tour of Secret Heroes. In this app, all the original heroes data--plus a set of new 'secret' heroes--has been moved to an Express server. Authentication happens with Auth0, and angular2-jwt is used for protecting routes, conditionally showing UI elements, and sending authenticated HTTP requests.

Wrapping Up

Stateless authentication has distinct advantages over traditional session-based auth. Keeping our APIs stateless makes them more agile and lets us easily port our apps to other platforms like mobile or desktop. With open source libraries, such as angular2-jwt, we can easily check for token validity and send authenticated HTTP requests with just a bit of configuration.
If you're interested in adding authentication to an Angular 1.x app, the things we went through here still apply, but there are a few differences to keep in mind. For instance, Angular 1.x has HTTP interceptors which can be used to attach the Authorization header to requests, so there's no need to wrap the $http service.
For more on Angular 1.x and 2 authentication, as well as tutorials about Angular in general, be sure to check out the Auth0 blog.