001c9ddc5ceb9829b6aaf24f5d28502a

I am software developer with a keen interest in open-source technologies, Linux, and native development. I've worked on many different platforms Android, iOS, Win32, Linux, FreeRTOS, the Web, and others. I've gone through the whole stack and I enjoy learning and using the latest technologies. I now work as a full-stack developer at Auth0.

Senior Engineer

Sebastian Peyrott

In this post you will learn about Single Sign-On (SSO) authentication and how to use it for your web apps

[Single Sign-On (SSO)](https://auth0.com/resources/whitepapers/definitive-guide-to-single-sign-on) authentication is now required more than ever. Nowadays, almost every website requires some form of authentication to access its features and content. With the number of websites and services rising, a centralized login system has become a necessity. In this post, we will study how **SSO authentication** is implemented for the web. Read on!

<AmpContent>
<amp-youtube
    data-videoid="Vp6kx4Sd_E0"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>
<NonAmpContent>
<div class='embed-container' style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;"><iframe style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;" src='https://www.youtube.com/embed/Vp6kx4Sd_E0' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

## Federated Identity Glossary

The concept of a centralized or linked electronic identity is known as *federated identity*. Federated identity systems handle several concerns:

- Authentication
- Authorization
- User attributes exchange
- User management

The **authentication** aspect deals with validating user credentials and establishing the identity of the user.

**Authorization** is related to access restrictions (e.g., is the user allowed to access X resource?). 

The **attributes exchange** aspect deals with data sharing across different user management systems. For instance, fields such as *"real name"* may be present in multiple systems. A federated identity system prevents data duplication by linking the related attributes. 

Lastly, **user management** is related to the administration (creation, deletion, update) of user accounts. A federated identity system usually provides the means for administrators (or users) to handle accounts across domains or subsystems.

SSO is strictly related to the **authentication** part of a federated identity system. Its only concern is establishing the identity of the user and then sharing that information with each subsystem that requires the data. Below, we focus on this crucial aspect of a federated identity system.

![What is single sign-on separator 1](https://images.ctfassets.net/23aumh6u8s0i/2xIzg7UIbBpGNvCeRsdn4k/32f29b73fc2b4bd33bac6fe124d9bfb1/what-is-sso-1)

## Single Sign-On (SSO) Authentication

Sooner or later web development teams face one problem: you have developed an application at domain X and now you want your new deployment at domain Y to use the same login information as the other domain. In fact, you want more: you want users who are **already logged-in** at domain X to be already logged-in at domain Y. This is what SSO is all about.

![Non-Single-Sign-On Scenario](https://images.ctfassets.net/23aumh6u8s0i/4pa532TumNn6TI3gQmMWEw/0a6182b447b75b24bea1b763c1ba73a1/non-sso-scenario)

The obvious solution to this problem is to **share session information** across different domains. However, for security reasons, browsers enforce a policy known as the [*same origin policy*](https://en.wikipedia.org/wiki/Same-origin_policy). This policy dictates that cookies (and other locally stored data) can **only be accessed by its creator** (i.e. the domain that originally requested the data to be stored). In other words, domain X cannot access cookies from domain Y or vice versa. This is what SSO solutions solve in one way or the other: sharing session information across different domains.

![No cookie sharing](https://images.ctfassets.net/23aumh6u8s0i/2WJQLWBpByFyth3ufF3Af0/5f341d8816d77f20dc05c5a2f31ec89f/same-origin-policy-forbids-this)

Different SSO protocols share session information in different ways, but the essential concept is the same: there is a **central domain**, through which authentication is performed, and then the **session is shared** with other domains in some way. 

For instance, the central domain may generate a signed [JSON Web Token (JWT)](https://auth0.com/docs/jwt), which may be encrypted using [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516). This token may then be passed to the client and used by the authentication domain as well as any other domains. The token can be passed to the original domain by a redirect and it contains all the information needed to identify the user for the domain requiring authentication. As the token is signed, it cannot be modified in any way by the client.

![SSO - Central authentication domain](https://images.ctfassets.net/23aumh6u8s0i/2GrAhJRypY1XQx3TIDbqzO/ecbd47c21f1e1c1fd334a239b9015a08/using-central-auth-domain)

Whenever users go to a domain that requires authentication, they are **redirected** to the authentication domain. As users are **already logged-in** at that domain, they can be immediately redirected to the original domain with the necessary authentication token.

![Single Sign-On Authentication](https://images.ctfassets.net/23aumh6u8s0i/4hakDPwQtaPfcDNwkd4C9x/e54ee76304953540b4b71fcccbaf690a/typical-sso-v2)


## SSO Authentication with Auth0

If you have been reading about SSO online, you have probably found that there are many different implementations: OpenID Connect, Facebook Connect, SAML, Microsoft Account (formerly known as Passport), etc. Our advice is to choose whatever is simplest for your development efforts. For instance, [SAML](https://auth0.com/docs/protocols/saml) is deeply entrenched in enterprise developments, so in some cases, it will make sense to pick that. If you think you will need to integrate your development with more than one alternative, don't despair: there are frameworks that allow interoperability between different SSO solutions. In fact, that's one of the things we do at Auth0.

<include src="SignupCTA" text="Try out Auth0 authentication for free." linkText="Get started →" />

You can go and check our [docs on Single Sign-On](https://auth0.com/docs/sso/single-sign-on) and the [Auth0 SSO samples](https://github.com/auth0/auth0-sso-sample).

If you remember the Typical SSO Scenario diagram we saw earlier, you can see how Auth0 comes to play in the next diagram:

![SSO with Auth0](https://images.ctfassets.net/23aumh6u8s0i/5n5APnJDhCtUiyZvyAG6rK/5a9faf400e436dd131bdee21b81c8761/auth0)

In this case, **Auth0 is the [Authentication Server](https://auth0.com/blog/what-is-an-authentication-server/)** and it works as a *bridge* between different SSO frameworks. 

<include src="ebook-ads/SsoGuide" />

## Conclusion

Single Sign-On authentication is here to stay. Decentralized systems are becoming more and more common and authentication is an essential aspect of all of them. SSO solves a big problem: how to manage the increasing number of users across a whole ecosystem of applications and services. Frameworks such as [OpenID Connect](https://auth0.com/resources/ebooks/the-openid-connect-handbook?ref=blog) and services such as the one we provide at Auth0 make [integrating Single Sign-On](https://auth0.com/learn/how-to-implement-single-sign-on/) into your new or existing applications much easier. If you are implementing authentication for a new application or service, consider integrating SSO from the get-go.

![What is single sign-on separator 3](https://images.ctfassets.net/23aumh6u8s0i/5L0CZk6C2On5CTXSHlE3MF/50e145cd648e88dd800f90ca19cfa1e4/what-is-sso-3)

What Is Single Sign-On Authentication (SSO) And How Does It Work?

ryan-chenkie

Ryan is a full-stack JavaScript developer and trainer who mainly works with React, Angular, Node, and GraphQL. He runs a consultancy where he builds apps for companies and also helps established dev teams with their modern JavaScript challenges.<br /><br />Ryan is a Google Developer Expert, the host of the Entrepreneurial Coder Podcast, the author of Securing Angular Applications, and an all-around fanatic about application security.

Developer

Ryan Chenkie

Learn how to add JWT authentication to your AngularJS 1.x app



> Adding authentication to any single page app comes with a set of challenges, and this includes apps built with AngularJS. Auth0 makes the process a lot easier with some open source libraries for saving and sending JSON Web Tokens, as well as a full authentication service that removes the need to write authentication logic yourself. If you want to get all the details of how to add auth to your AngularJS 1.x app, this screencast series is for you. If you'd like, you can go straight to the [code](https://github.com/auth0-blog/angular-auth) or checkout the [AngularJS + Auth0 docs](https://auth0.com/docs/quickstart/spa/angularjs/no-api).

In the last part of our AngularJS authentication series, we'll take a closer look at some of the features that Auth0 provides. Specifically, we'll see how we can easily add social login with Twitter and enable multifactor authentication with Google Authenticator. These features are available with just some simple configuration, which saves us a lot of time and effort.

* **<a class="screencast-anchor" href="#enabling-social-login" target="_self">Enabling Social Login</a>**
* **<a class="screencast-anchor" href="#enabling-multifactor-authentication" target="_self">Enabling Multifactor Authentication</a>**
* **<a class="screencast-anchor" href="#wrapping-up" target="_self">Wrapping Up</a>**

<h2 id="enabling-social-login">Enabling Social Login</h2>

<iframe width="560" height="315" src="https://www.youtube.com/embed/zzcX-kbvHHQ" frameborder="0" allowfullscreen></iframe>

### **Transcript**

Why don't we go through the steps to see how to enable another social provider in our application. If we remember, when we log in, we've got this option to sign in with Google, and that came by default for us because that's the only social provider that's enabled by default when we sign up for Auth0. But let's say that we want users to also be able to sign in with their Twitter account. To do this, let's go over to our Auth0 dashboard, and that's at `manage.auth0.com`. And then, over here in the connections area, we can go to "Social" and we can see a list of all of the social providers that we can use for our Auth0 account.

And, once again, we're able to use two of these social providers at no cost at all, with the free plan. So let's say we want to use Twitter, well, we can just come over here and enable it like this. And what we'll see right away is that we've got to enable some settings here for our Twitter connection, and we need a consumer key and a consumer secret. So why don't we go through the steps to get a consumer key. And right at the start here, what we get is a link to go the Twitter application management area where we can register a new application.

So let's create a new app, and this is where we'll put in some of the details for our application. The name, for this case, can be "AngularJS Auth", and the description will be "AngularJS authentication sample". And the website, I'll just use my own in this case. And the callback URL is going to come from Auth0. So this is going to be specific to our Auth0 account, and we can actually just grab it from the documentation right down here in step number three. So let's grab that here, and we'll copy it over to our callback URL input right there.

And then we'll come down below, and let's just agree to the terms and we'll go create our application. So here we can see the application has been created, and we're able to get our keys and access tokens from this tab right here. And just like always, I'm going to be regenerating my keys right after I'm finished recording, so no sense in trying to use them. But anyhow, this is where we get our consumer API key and our consumer secret. So let's head back over here to the documentation and just check for any additional steps that we need to take.

So what we can do next is copy over our consumer key, so let's grab this. We'll just copy it as such and come back over to our social connections, and let's paste that in here. And, likewise, let's grab our consumer secret. And now let's hit "save". And it says, "Connection settings saved." What we can do is test it out. So we've saved that, let's get out of here, and let's give it a try. We'll flip this to the on position and we can try it if we hit "continue". Let's give it a try down here. So we get, "Authorize AngularJS Auth to use your account," we'll say, "Sign in." And this where we can sign in with our Twitter credentials. And we get the message, it works. All right, perfect.

We can close down all of these tabs now, and let's head back over to our application and let's try signing in with our Twitter ID. So let's try logging in again. Here we can see that my Twitter account is still remembered because I've just tested it out in the Auth0 dashboard. So if I click there, what we'll get is a redirection back to the application after the authentication goes through. And just like we were authenticated with username and password before, we see that we've got a JSON Web Token in local storage. We've got our ID token and our profile, so we're good to go to access our application. So there's an example of how we can enable a social connection in Auth0, and then make use of it in our application. In the next lecture, we'll see how to use multi-factor authentication so that we can make our app even more secure.
<hr>

<h2 id="enabling-multifactor-authentication">Enabling Multifactor Authentication</h2>

<iframe width="560" height="315" src="https://www.youtube.com/embed/1f169IVVvgk" frameborder="0" allowfullscreen></iframe>

### **Transcript**

Depending on how secure we want our app to be, we might benefit from using something like multifactor authentication. Perhaps you've seen this before in some other application you use. It's where you sign in with your credentials, say your user name and your password, and then you get sent a verification number to your phone which you then need to enter into the application to verify your identity. This is something that can be a little bit tricky to code from scratch, but thankfully Auth0 makes it really simple.

Let's go back over to our dashboard, `manage.auth0.com`. If we come over here to the "Multifactor Auth" link we can enable multifactor auth, then we've got our choice of two different providers. We can use Google Authenticator or Duo. Let's just try Google Authenticator in this case. What we're going to need to do is actually download Google Authenticator on our phones. If you're building this into your own application, you would need to instruct your users to get Google Authenticator so that they can go through the multifactor auth steps.

What we see down here is a code snippet that we need to modify so that we can tell Auth0 to use multifactor auth in our Angular application. To do that, we actually need to provide the client ID for any application that we want to enable multifactor auth on right here within this array. Let's do that. Let's go over to our applications link, and let's find the client ID for the app. Let's grab this client ID here. We'll come back over to multifactor auth. Let's just place that right here within this array. We'll get rid of everything there. We will paste in our client ID.

Now let's give it a shot in our application. Back over here in our app let's log out. Then, let's log in again. We'll go to log in. We'll choose our Twitter account. What we'll see here is that we need to enter our two step verification code. The way that this works with Google Authenticator is we go into our Google Authenticator app. I'm just opening the application on my phone right now. We actually need to scan this QR code here. If you're in your Google Authenticator app it's just the plus sign up at the top right. We can scan barcode. Then, let's place it up to the screen. There we go. I've got my code and I'm going to enter it now. If the code checks out, we should be able to get in. There we go. We've got our profile and our token saved again.

Applying multifactor auth to our application is very simple with Auth0. I'm sure you can see the benefits of it. It's a really big step in securing our application even more.

<include src="TweetQuote" quoteText="Applying multifactor auth to our application is very simple with Auth0."/>

<hr>

<h2 id="wrapping-up">Wrapping Up</h2>

<iframe width="560" height="315" src="https://www.youtube.com/embed/Dcs5WdtJHno" frameborder="0" allowfullscreen></iframe>

<script>
$(window).load(function() {
  $('.screencast-anchor').attr('target', '_self');
});
</script>


AngularJS Authentication Screencast Series - Part 4

AngularJS Authentication Screencast Series - Part 3

AngularJS Authentication Screencast Series - Part 2



> Adding authentication to any single page app comes with a set of challenges, and this includes apps built with AngularJS. Auth0 makes the process a lot easier with some open source libraries for saving and sending JSON Web Tokens, as well as a full authentication service that removes the need to write authentication logic yourself. If you want to get all the details of how to add auth to your AngularJS 1.x app, this screencast series is for you. If you'd like, you can go straight to the [code](https://github.com/auth0-blog/angular-auth) or checkout the [AngularJS + Auth0 docs](https://auth0.com/docs/quickstart/spa/angularjs/no-api).

In the first part of the screencast series, we'll take a look at how authentication works for round-trip apps, and the challenges that exist when it comes to using these traditional methods in single page apps. We'll then learn about [JSON Web Tokens](https://jwt.io/introduction), which provide a better way to do [authentication in AngularJS apps](https://auth0.com/learn/angularjs-authentication/).

* **<a class="screencast-anchor" href="#what-well-build" target="_self">What We'll Build</a>**
* **<a class="screencast-anchor" href="#traditional-authentication" target="_self">Traditional Authentication</a>**
* **<a class="screencast-anchor" href="#the-tricky-parts" target="_self">The Tricky Parts of AngularJS Auth</a>**
* **<a class="screencast-anchor" href="#json-web-tokens" target="_self">JSON Web Tokens</a>**

<h2 id="what-well-build">What We'll Build</h2>

<iframe width="560" height="315" src="https://www.youtube.com/embed/RuubsWkjwrM" frameborder="0" allowfullscreen></iframe>

### **Transcript**

So this course is going to cover all about how to authenticate our angular apps with JSON Web Tokens and we're going to use Auth0 to do this.

So this is a service that provides a really nice login box that's ready to go. And really all we need to do is provide some functions to our application to tie into the service. And once we've done that, we'll be able to get our users' profile and their token, and save those in local storage. And then we can use the token to make requests for secured resources on our server.

So this is what the application will look like in the end. Now let's dive right in and get started.

<hr>

<h2 id="traditional-authentication">Traditional Authentication</h2>

<iframe width="560" height="315" src="https://www.youtube.com/embed/V_9XLxOGXp8" frameborder="0" allowfullscreen></iframe>

### **Transcript**

To lay the ground work for this course, let's take a look at how authentication is done in what I'll call a traditional web app. A traditional web app has a lot of definitions. I'll think of it as an application where the user has to refresh the page to get some new data or to send data to the server. If the user comes to your website or your web app and they want to submit some data to be saved in the database, when they do that to get a response back, they actually have to go through a full page refresh. Likewise, when they want to get some new data from the server, they actually have to refresh the page to get that data. 

We're probably all quite familiar with this. This is kind of how the web was built. You have to send a request and refresh the page to get new stuff. As you probably know, since you're working with Angular, it's a framework for building what we call single page apps. The single page app, of course, is one where you don't have to go through that full page refresh to submit data or to get new data. Single page apps actually send and receive data through XHR requests which happen behind the scenes. What we get with that ultimately is the feel of a native desktop application which makes for a much nicer user experience. That's probably why you're building applications with Angular. You want to have that snappy fluid desktop-like feel. 

Back to authentication. How does it actually happen in a traditional web app? Typically it looks like this. The user will come to your application. They will log in with their credentials, their user name and their password. Those credentials get submitted and sent to the server where they're checked against a database. If everything matches up, a session gets created on the backend (on the server) for that user. The session is this piece of data that the server can use to know that the user is authenticated. Now when the user needs to navigate to another spot in the application, let's say they go to their profile page next (and that happens through a round trip request), the server is able to know that the user is authenticated. 

This raises the question: how does the server actually know who it is that's making these requests for data. It would seem that the server needs some way to actually be able to verify that the user who has sent the request is the user that's actually authenticated. 

This is where cookies come in. You might be familiar with cookies. These are the small pieces of data that get saved in the user's browser. Cookies actually get automatically sent to the server on every request to it. Since cookies hold pieces of information, what we can do is have that cookie store an identifier for the user. This is typically what happens. When the user's authentication is valid, the response that comes back to them contains a cookie that gets saved. This cookie has an identifier for that user. Then, the cookie automatically gets sent to the server whenever the user navigates to another page. It's the cookie's information that gets verified against the session that tells the server whether or not that user is who they say they are. The server is then able to know that the user should still be authenticated when that session exists on it. Because this happens automatically, the user doesn't need to send their credentials every time and their credentials don't need to be checked against the database every time they make a request, or at least not until the cookie has expired. 

This method of authentication works pretty well for traditional web apps (for those that require the full page refresh), but there are some limitations to using cookies and sessions together for modern applications like the ones that we build with AngularJS. We'll talk about what those limitations are and how to get around them in the next lecture.

<hr>

<h2 id="the-tricky-parts">The Tricky Parts of AngularJS Auth</h2>

<iframe width="560" height="315" src="https://www.youtube.com/embed/AglJkyH1dt0" frameborder="0" allowfullscreen></iframe>

### **Transcript**

So if you've worked with Angular for any amount of time, you're probably aware that one of the best ways to work with a backend is through a data API, and in particular, a data API that accepts and returns JSON data. Now, this obviously isn't the only way that we can work with data in our Angular application, but it's ultimately one of the easiest and most flexible ways to go about it.

So when we do this, what we're effectively doing is we're building two different applications, two distinct and separate apps. And one of them is for the client side. That's the Angular application. And it's really just concerned with the user's browser. And then we have our server side application, which is built with something like Node.js or Ruby on Rails or PHP or whatever server side language or framework we like.

And then we connect these two applications through a data API. And that communication happens via XHR requests from the client to the server. So when we build our data API, chances are that we're going to want to build a RESTful API. And one of the core tenets of REST is that things should be stateless. And so what this means is that when we construct a request that goes to our API, that request should always return the same resource.

And with traditional roundtrip authentication where we set up sessions to check if the user is authenticated, well that sets up some state on our server, which can effectively change the result that we get back for a given request. And so this breaks that core tenet or REST being stateless. And then there's some issues related to how modern application ecosystems work. And so things are changing with the way that we build and distribute applications these days, and this has some implications for authentication.

So for instance, we can't easily share a user's session across multiple servers. What we're seeing more and more these days is that an application is not going to use just a single server for all of its resources and all of the things it needs to do, but rather it's going to rely on multiple different servers. So with traditional authentication, everything works fine if we have just a single server, but as soon as we get more than one involved, then things get tricky.

There are ways to share sessions across different servers, but it's not really easily done. Another issue is that cookies don't flow downstream. So another pattern that we're starting to see in modern application development is that our server--our application server--might rely on a downstream server or multiple downstream servers to get its work done. Now, the problem with this is that since we need cookies to properly authenticate in a traditional authentication setup, well, cookies can't flow to those downstream servers so we can't really go beyond our single application server.

And then we ultimately want to be able to share our API across different applications. We want to be able to write an application for the web and then maybe also a mobile application. And then, who knows, maybe even a desktop app. But we don't want to have to rely on different data resources for each of those applications. Instead, what we want to be able to do is use that same API across our different apps. And with traditional authentication, this is just pretty tricky when we have to deal with cookies.

So those are some of the issues that are more related to the server side, but what about the front end? What about Angular in particular? Well, like we talked about, in a good Angular setup, our Angular app doesn't have any kind of stateful connection to a backend. Rather, it's going to fulfill its data needs, whatever those needs may be, for sending data or receiving data, through XHR requests to the API.

And so because of this, because of this statelessness, we need to take some things into consideration. So firstly, we need to be able to limit access to certain routes in our Angular app. So certain parts of the application should only be accessible to users who are authenticated. This is just sensible application design. So even though we don't have any kind of stateful authentication going on, we still need to make it possible for Angular to know that a user is logged in or not.

We also need to be able to show or hide certain parts of the user interface depending on the user's authentication state. So for example, we might have a spot in our navbar where the user's name and profile photo show up. Well, we need to be able to either hide or show that depending on whether or not the user is logged in. So again, Angular isn't connected in a stateful way to a backend. 

And given this, how can Angular know whether or not the user is authenticated if there's no kind of session or stateful connection made? And even more fundamentally, how are we able to do any authentication at all if we don't involve sessions and cookies and state? Well, it turns out there's a really nice way to do this with a newer standard called the JSON Web Token. And we'll talk about the JSON Web Token and what it's all about in the next lecture.

<hr>

<h2 id="json-web-tokens">JSON Web Tokens</h2>

<iframe width="560" height="315" src="https://www.youtube.com/embed/LLWX1Cd8vJ0" frameborder="0" allowfullscreen></iframe>

### **Transcript**

So what exactly is a JSON Web Token? Well it's an open standard under RFC that describes a way to transmit what are known as claims between two parties in a secure way. Now that's a mouthful, so let's break it down. 

Essentially, JWTs communicate JSON objects, and one of the objects in them is a set of claims. So what exactly is a claim? Well put simply, it's a piece of information that is asserted about a subject. And for the case of authentication, the subject is the user. 

So what exactly does a JWT look like? Well here's an example. And as you can see here, this doesn't really mean a whole lot to us as humans, and that's because JWTs are encoded. And in fact, there are three distinct parts that are each encoded as you might have guessed here by this dot separator. 

All right, so why don't we take a look at what a decoded JWT looks like so that we can see what's going on with these three parts. Okay so I'm over here at jwt.io, and this is a website made by Auth0 that gives us some really nice resources and information about JSON Web Tokens and also a really nice debugging tool so that we can actually inspect our tokens. 

So over here on the left, we can drop in and encode a JWT. And then over here on the right, we get the decoded values from it. And this actually reveals to us the three different parts on the token. We've got a header, a payload, and a signature. So let's run through each of these three parts. 

The header contains information about the algorithm and the token type. And so we can see here, our algorithm that we're going to be using is HS256 and the type is JWT for "JSON Web Token". 

Now the payload is where we actually store the claims that we were talking about. So those claims--being assertions about a subject--are going to be stored in this object within the payload. And there are certain claims that are registered with the JWT specification, and these are claims like `sub` for subject, which in this case is our username of John Doe, and `iat` for issued at, that's the time that the token was issued at, and also `exp` for expiry and this gives us an expiry time for the token so that we can limit how long it can be used for. 

And then we've also got claims that we can define our self. So we can provide claims like `name`, and `admin`, and those can be any kind of arbitrary keys and values that we like. Now we aren't forced to use any of the registered claims, and we can provide any kind of arbitrary claims that we want within the payload as well. So this gets really useful for transferring information. 

Now the header and the payload obviously look different over here in the encoded JWT than they do over in the decoded JWT and that's because each of these is Base64 URL encoded. So the objects are encoded and then they're tacked together with this dot separator. 

We also see down here in the signature what looks to be encoding but it's actually a bit different. So what's happening in the signature is that we're taking the encoded header, plus the encoded payload, plus a secret--so this will be a secret that lives on our server--and then we're hashing that using the HS256 algorithm. And so what this does is it effectively secures or digitally signs our token because as long as we have an unguessable secret key, we can be sure that the information within the JSON Web Token doesn't get tampered with.

So obviously the key that we see here which is just the word "secret" isn't all that secure. In reality, we would want a long and unguessable secret key. 

Okay so that's what JSON Web Tokens look like but how are they used for authentication in Angular apps? Well essentially what we need to make that possible is a way for the user to send their credentials to a server and then receive a JSON Web Token back if everything checks out. And then on every subsequent request that gets made to the server for secured resources, the user sends the JSON Web Token back. 

And then back at the server it can be checked against that secret key and be verified. And so how does the user send the JWT back to the server once they have it? Well what we do is we attach it as an `Authorization` header using the `Bearer` scheme. So HTTP requests just need to attach an extra header, which is the JWT and that gives us a way to authenticate and verify our user's identity. 

So that covers what JSON Web Tokens are and how they work. Now that we have that understanding, let's start implementing it in an angular application.

<script>
$(window).load(function() {
  $('.screencast-anchor').attr('target', '_self');
});
</script>


AngularJS Authentication Screencast Series - Part 1

bc94ff6211e645a2bdb4fdc60e23ad85

Former Auth0 Employee

Kassandra Perch

This episode shows the difference in Lock between Redirect and Popup modes.


This is Kassandra with Auth0. This is the third episode of our Getting Started with Lock series. We also have [episode 1: implementing Lock](https://auth0.com/blog/2016/02/03/getting-started-with-auth0-lock-series-implementing-lock/) and [episode 2: using customization options](https://auth0.com/blog/2016/02/10/getting-started-with-lock-episode-2-using-customization-options/)

<include src="Vidyard" id="ejD2jBGyJDcRSnFFasYWz5" />

In this episode, we're going to talk about the two mode Lock has of interacting: redirect mode and popup mode. We'll also talk about how to implement these modes in regular webapps and single-page applications.

The rule of thumb for when to use these modes is determining where you store state in your web application; if your state is stored on the client and page refreshes affect your app's ability to run, popup mode will work with your app. However, **redirect mode is the recommended mode for Lock**, and you can implement it on a single-page application. There are almost no reasons not to use redirect mode when writing a regular web application, as page refreshes are already part of the architecture there.

First, we'll talk about implementing redirect mode on a regular webapp. This will look very familiar to viewers who watched episode 1.

We're going to make some assumptions here: one is that you have routes on your server that manage user state at `/login`, `/logout`, and an oauth-style callback at `/callback`. You can find an example of these routes [in our quickstarts for regular web applications](https://auth0.com/docs/quickstart/webapp/) We also assume you have added `http://localhost:3000/callback` to your Allowed Callbacks list in the App Dashboard.

As for your javascript, you need to keep in mind that *we do not explicitly tell Lock which mode it needs to run in.* Instead, we send a `callbackURL` parameter in our options object in order to designate redirect mode. Your `lock.show()` call should look something like this:

```javascript
var lock = new Auth0Lock(AUTH0_CLIENT_ID, AUTH0_DOMAIN);

lock.show({
  callbackURL: 'http://localhost:3000/callback'
});
```
That's it! You can now log in with redirect mode in regular webapps. Next, we'll look at implementing popup mode in a single-page application.

In order to do this, I made some modifications to my jade template:

```jade
  h1= title
  p Welcome to #{title}
    span.username
  img.user-avatar
  br
  button#login Login
  button#logout Logout
```

This is because we'll be staying on this page instead of being redirected to a user page like the last example. As for the javascript, in order to set Lock into popup mode, you pass a callback as the second parameter to `lock.show()`:

```javascript
lock.show({}, function(err, profile, id_token){
  if(err){
    console.log('error logging in', err);
    return;
  }
  $('#login').hide();
  $('#logout').show();
  $('.username').html(', ' + profile.nickname + '!');
  $('.user-avatar').attr('src', profile.picture);   
});
```

This callback recieves an error `err` (`null` if successful), a `profile` object representing our logged-in user, and an `id_token`: this is the JWT that will authenticate your user, and is useful if you will be making calls to APIs that you protect with JWT authentication. You can then modify the DOM, or your application state, or whatever you need with the profile information.

**Please remember that redirect mode is the recommended use of Lock [due to browser compatibility issues](https://auth0.com/docs/libraries/lock/v10/popup-mode). Please only use popup mode if you must.**

Finally, we'll talk about implementing redirect mode in a single-page application. The best way to go about this is to check your application hash for an ID token on your callback page, then, if it is found, use that ID token to get the user's profile from Auth0. To parse and use the ID token from the hash, Lock provides `lock.parseHash()` and `lock.getProfile()`:

```javascript
var hash = lock.parseHash(window.location.hash);

if(hash){
  if(hash.error){
    console.log('error logging in.');
  }
  if(hash.id_token){
    lock.getProfile(hash.id_token, function(err, profile){
      if(err){
        console.log('error fetching profile!', err);
      } else {
        $('#login').hide();
        $('#logout').show();
        $('.username').html(', ' + profile.nickname + '!');
        $('.user-avatar').attr('src', profile.picture);
      }
    });
  }
}
```

To finish this, we'll need to modify our `lock.show()` call. First, we'll set the `callbackURL` to the URL of our single-page application. We'll set the `responseType` to `token`-- this usually defaults to `code`, but we need an ID token in order to get the user profile.

```javascript
lock.show({
  callbackURL: 'http://localhost:3000/',
  responseType: 'token'
});
```

And now you have redirect mode set up on your single-page application!

In the next episode of this series, we'll talk about customizing Lock's UI further to suit your application's needs.

I'm Kassandra with Auth0, thanks for reading!


Getting Started with Lock episode 3: Redirect vs Popup Mode

This is the second episode of the Lock screencast series, where we show the various customization options in Lock.js


Hi, this is Kassandra with Auth0. In [the first episode of our new Getting Started with Lock screencast](https://auth0.com/blog/2016/02/03/getting-started-with-auth0-lock-series-implementing-lock/), we talked about how to implement Lock. Today, we'll be talking about customizing Lock with the various options in our Lock library.

<include src="Vidyard" id="aBsEczc79qmKefGdg6o4CP" />

But first, I'd like to introduce viewers to the [Lock Playground](https://auth0.github.io/playground/). This is a tool Auth0 has that allows users to test the options out on Lock without having to implement it! The code on the left affects the window on the right in real time. A documented list of all of the options are available [in our docs](https://auth0.com/docs/libraries/lock/customization).

![Auth0 Playground](https://images.ctfassets.net/23aumh6u8s0i/7GRbERkpUEt4wGDkrAxbKU/ee65f91956278c63bbabb6a17285e6e7/playground)

Here's a snapshot of the options we'll be looking at today:

```javascript

lock.show({
	connections: ['Username-Password-Authentication', 'Facebook'],
	dictionary: 'en',
	icon: 'https://mycdn.com/myImage.png',
	closable: true,
	socialBigButtons: true,
	focusInput: true,
	usernameStyle: 'email',
	gravatar: true,
	disableSignupAction: false,
	disableResetAction: false
});

```

First, we'll talk about the `connections` option: this option allows us to select a subset of our configured login providers to show to a user. This is handy if you have configured a login type, but do not want it to be an open option to potential users. This is an array of the connections you'd like to show.

Next is `dictionary`: you can convert the dialogue to a different language by using its language code (e.g. 'es' for Spanish).

The `icon` option accepts a URL and allows you to change the logo at the top of the dialog to an image of your choosing. Recommended size is 85x85px.

`closable`, when set to `true`, allows users to close the Lock dialog, and can be set to false to prevent users from dismissing your login screen.

You can change the presentation of the social provider buttons using the `socialBigbuttons` option: this defaults to `false` if the username and password dialog is shown, and `true` otherwise. However, you can change it to suit your needs.

`focusInput` places focus on the username field in the Lock dialog, when set to `true`. This can be especially handy in situations where your login dialog is mandatory or overlays the screen-- however, it's best set to `false` in optional or embedded contexts. (It's set to false in the playground so that our cursor stays with the code.)

The `usernameStyle` option is handy if you'd rather use usernames instead of emails to identify themselves. By default, the prompt in username is set to 'Email', but by setting `usernameStyle` to `username`, the prompt will change to 'Username'.

The `gravatar` options, which defaults to `true`, watches the email entered in the Email field, and, if it matches a gravatar account, will replace the logo at the top of the dialog with the user's gravatar.

When you are showing your username and password login option, you will see a 'Sign Up' tab and a 'forgot your password?' link on the Lock dialog. You can disable these by setting `disableSignupAction` and `disableResetAction` to `true`.

In our next episode, we'll talk about the differences between Lock's two modes: popover and redirect.

Thanks for reading!


Getting Started with Lock Episode 2: Using Customization Options

Learn all about the new Angular 2 router and how to set it up in your app.

Angular 2 Series - Part 4: Component Router In-Depth

Learn the basics of dependency management and data sharing for microservices architectures

Intro to Microservices, Part 4: Dependencies and Data Sharing

In this tutorial learn how to integrate LDAP and Active Directory (AD) with your C# projects

Using LDAP and Active Directory with C# 101

Learn the differences between $http in Angular 1.x and Http in Angular 2. Find out how to use the RxJS Observables that Http returns.



---
**TL;DR:** Making **HTTP requests in Angular 2 apps** looks somewhat different than what we're used to from Angular 1.x, a key difference being that Angular 2's **Http** returns **observables**. In this tutorial, we cover how to use Http to make requests and how to handle the responses. We'll also see how we can do basic authentication for an Angular 2 app. Check out [the repo](https://github.com/auth0/angular2-http) for the tutorial to see the code.

This is Part 3 in our Angular 2 series. Be sure to check out [Part 1 on Pipes](https://auth0.com/blog/2015/09/03/angular2-series-working-with-pipes/) and [Part 2 on Models](https://auth0.com/blog/2015/09/17/angular-2-series-part-2-domain-models-and-dependency-injection/).

---

It's fair to say that most of Angular 2 looks and feels completely different than Angular 1.x, and the **Http** API is no exception. The **$http** service that Angular 1.x provides works very nicely for most use cases, and is fairly intuitive to use. Angular 2's Http requires that we learn some new concepts, including how to work with **observables**.

In this tutorial, we'll look at some of the key differences in the way that Angular 1.x and 2 implement **HTTP requests**, and we'll also see how to make requests and handle responses. Incidentally, the sample we use to test out **Http** will also let us see the basics of adding authentication to an Angular 2 app.

It's important to note that the Http implementation for Angular 2 is still a [work in progress](https://github.com/angular/angular/issues/2793), and a lot of things are still in flux or aren't complete yet.

## Differences between Angular 1.x $http and Angular 2 Http

**Angular 2's Http implementation** again provides a fairly straightforward way of handling requests, but there are some key differences. For starters, **HTTP calls in Angular 2** by default return observables through [RxJS](https://github.com/Reactive-Extensions/RxJS), whereas $http in Angular 1.x returns promises. Using observable streams gives us the benefit of greater flexibility when it comes to handling the responses coming from HTTP requests. For example, we have the potential of tapping into useful RxJS operators like `retry` so that a failed HTTP request is automatically re-sent, which is useful for cases where users have poor or intermittent network communication. We'll see later in the article how we can implement RxJS operators in our Http observables.

In Angular 2, Http is accessed as an injectable class from `angular2/http` and, just like other classes, we `import` it when we want to use it in our components. Angular 2 also comes with a set of injectable providers for Http, which are imported via `HTTP_PROVIDERS`. With these we get providers such as `RequestOptions` and `ResponseOptions`, which allow us to modify requests and responses by extending the base class for each. In Angular 1.x, we would do this by providing a `transformRequest` or `transformResponse` function to our `$http` options.

In Angular 1.x we can transform requests globally in the application's `config`.

```js
.config(function($httpProvider) {
  $httpProvider.defaults.transformRequest = function(data) {
    return JSON.stringify({name: "Ryan"});
  }
});
```

Whereas in Angular 2, we would extend the `BaseRequestOptions`.

```js
class MyOptions extends BaseRequestOptions {
  body: string = JSON.stringify({name: "Ryan"});
}

bootstrap(App, [HTTP_PROVIDERS, provide(RequestOptions, {useClass:MyOptions})]);
```

## Http in Action

Let's take a look at how we can perform some basic requests with Http. We'll see how to work with `POST` and `GET` requests by using our trusty [NodeJS Chuck Norris quote backend](https://github.com/auth0/nodejs-jwt-authentication-sample), which will require us to retrieve and store a JWT, and thereby implement basic authentication.

## Getting Started

As we have in our other Angular 2 articles, we'll use [Pawel Kozlowski's](https://twitter.com/pkozlowski_os) [ng2-play](https://github.com/pkozlowski-opensource/ng2-play/) repo for this tutorial. To get started, clone the repo and run `npm install`, then `gulp play`.

We also need to get our random quote server running. With the Angular 2 seed project installed, let's clone and install the quote server in the root of our project.

We also need to set up our `app` component by importing what we need and providing a template.

```js
// app.ts

import {Component, View} from 'angular2/angular2';
import {Http, Headers} from 'angular2/http';
import {CORE_DIRECTIVES, FORM_DIRECTIVES} from 'angular2/angular2';

@Component({
  selector: 'app'
})

@View({
  directives: [ CORE_DIRECTIVES, FORM_DIRECTIVES ],  
  template: `
  <header>
    <h1 class="title">Angular 2 HTTP</h1>
  </header>

  <section>
    <h2>Login</h2>
    <form #f="form" (ng-submit)="authenticate(f.value)">
      <div ng-control-group="credentials">
          <label for="username">Username</label>
          <input
            type="text"
            id="username"
            ng-control="username"
            required>

          <label for="password">Password</label>
          <input
            type="password"
            id="password"
            ng-control="password"
            required>
      </div>

      <button>Login!</button>

    </form>

  </section>

  <section>
    <h2>Random Quote</h2>
    <hr>
      <h3>{{ "{{randomQuote" }}}}</h3>
    <button (click)="getRandomQuote()">Get Random Quote!</button>
  <section>

  <section>
    <h2>Secret Quote</h2>
    <hr>
    <h3>{{ "{{secretQuote" }}}}</h3>
    <button (click)="getSecretQuote()">Get Secret Quote!</button>
  <section>
  `
})

export class App {

  constructor(public http: Http) {

  }

}

bootstrap(App, [HTTP_BINDINGS])
```

As you can see, we've imported some familiar pieces like `Component` and `View`, but we are also pulling in `Http` and `Headers`. We'll see it later on, but we can modify the headers we send in our requests with the `Headers` class.

We're making use of a form for the user to eventually provide their credentials. The form calls an `authenticate` method on submit.

In the `App` class, we're passing `Http` to the constructor so that we can use it in our class methods.

## Simple GET Request

Let's start with a simple `GET` request to the `api/random-quote` route which doesn't require authentication.

```js
getRandomQuote() {
  this.http.get('http://localhost:3001/api/random-quote')
    .map(res => res.text())
    .subscribe(
      data => this.randomQuote = data,
      err => this.logError(err),
      () => console.log('Random Quote Complete')
    );
}

logError(err) {
  console.error('There was an error: ' + err);
}
```

The `getRandomQuote` method starts off looking pretty familiar--we do an `http.get` request by passing in a URL as an argument. Remembering `$http` from Angular 1.x, this is where we would tap into the promise that gets returned by using `.then`, but as you can see here, we're doing something pretty different.

As was mentioned earlier, **HTTP calls in Angular 2** return observables, so we need to use RxJS methods to operate on them. The first thing we do is map the values that are returned as text, since our call to the `api/random-quote` endpoint returns text. If we were expecting a JSON response, we would call `res.json()` instead. After this, we need to **subscribe** to it so that we can **observe** values that are returned.

<include src="TweetQuote" quoteText="HTTP calls in Angular 2 return observables, so we need to use RxJS methods to operate on them."/>

An observable subscription takes three functions to handle what happens as the stream is observed. The first function is the **next** case, or what happens when the HTTP call is successful. If the call is successful, we're saying that the data returned should be put on a property `randomQuote` so it can be displayed in the view. The second function is the **error** case, and in our example we are logging any error messages to the console by calling our `logError` method. Finally, the third function defines what happens once the call is **complete**, and here we are simply logging out the things are finished.

Let's test that out to make sure it works.

![angular2 http $http example](https://images.ctfassets.net/23aumh6u8s0i/3OP3Z3TjFP2iMFkiVN3XAD/b75a0e2b9229dc18e43fee1ff97be2fc/angular2-http-1)

## POST Request with Modified Content Type

Our `authenticate` method will need to make a `POST` request to the back end and specify the content type so that we can send our credentials. For this, we'll use `Headers`.

```js
// app.ts

...

class CredentialsModel {
  username: string;
  password: string;
}

...

authenticate(data) {
  var username = data.credentials.username;
  var password = data.credentials.password;

  var creds = "username=" + username + "&password=" + password;

  var headers = new Headers();
  headers.append('Content-Type', 'application/x-www-form-urlencoded');

  this.http.post('http://localhost:3001/sessions/create', creds, {
    headers: headers
    })
    .map(res => res.json())
    .subscribe(
      data => this.saveJwt(data.id_token),
      err => this.logError(err),
      () => console.log('Authentication Complete')
    );
}

saveJwt(jwt) {
  if(jwt) {
    localStorage.setItem('id_token', jwt)
  }
}

...
```

The `authenticate` method accepts `data` that is passed down from the view when the form is submitted. We're grabbing the username and password from it and making a `creds` string in the form that the server expects.

We need to say that the content type should be `application/x-www-form-urlencoded` and this can be done by appending a header onto our `headers` instance. Then we simply pass this as a header in the options object when we make the `POST` request. From here, the returned observable is handled in the same way that we saw in the `GET` request, but this time the response is JSON, so we use `res.json()`. We also call the `saveJwt` method and pass it the token that is received to save it in local storage.

## GET Request with Authorization Header

Now that we know how to modify headers, sending the JWT as an `Authorization` header is simple.

```js
// app.ts

...

getSecretQuote() {

  var jwt = localStorage.getItem('id_token');
  var authHeader = new Headers();
  if(jwt) {
    authHeader.append('Authorization', 'Bearer ' + jwt);      
  }

  this.http.get('http://localhost:3001/api/protected/random-quote', {
    headers: authHeader
  })
  .map(res => res.text())
  .subscribe(
    data => this.secretQuote = data,
    err => this.logError(err),
    () => console.log('Secret Quote Complete')
  );

}

...

```

We can check this in the browser to make sure our call to the protected endpoint works.

![angular2 http $http observables rxjs](https://images.ctfassets.net/23aumh6u8s0i/7MDfOrK8h8fqU4MkXg98Zq/aa05c56ac6ec9575ea934901e66c3e14/angular2-http-2)

## What Can We Do with Observables?

You might be wondering why Http doesn't just return promises like it used to, so we can stick to our familiar methods for resolving HTTP calls. The fact of the matter is that we can do much more with observables than promises. With observables, we have a [whole bunch of operators](https://github.com/Reactive-Extensions/RxJS/blob/master/doc/gettingstarted/categories.md) to pull from, which let us customize our streams in nearly any way we want.

If you haven't worked with observables before, you can get an idea of how they work in our recent post on [Authenticable Observables](https://auth0.com/blog/2015/09/10/jwt-authentication-with-observables/).

It should be noted that the [Angular team is still deciding](https://github.com/angular/angular/issues/4390) on the best way of implementing the RxJS operators with Http, which means these operators aren't all available for use just yet.

We can get a taste for how they work by plugging in some simple operators. For example, in our `GET` call to `api/random-quote`, we can attach a filter.

```js
// app.ts

...

getRandomQuote() {
  var count = 0;
  this.http.get('http://localhost:3001/api/random-quote')
    .map(res => res.text())
    .filter(x => x.length > 100)
    .subscribe(
      data => this.randomQuote = data,
      err => this.logError(err),
      () => console.log('Random Quote Complete')
    );
}

...
```

Now only quotes with a length greater than 100 characters will come through. If we click the "Get Random Quote" button a few times, we see it at work.

We can also delay our subscription if we want. Here we wait two seconds before printing the quote to the screen.

```js
// app.ts

...

  .map(res => res.text())
  .delay(2000)
  .subscribe(
    data => this.randomQuote = data,
    err => this.logError(err),
    () => console.log('Random Quote Complete')
  );

...
```

While that might not be the most useful, what we will really benefit from once Http is solidified are operators like `retry`. If we were expecting network connectivity issues, we could define a number of times to retry the request.

```js
// app.ts

...

  .retry(3)
  .map(res => res.text())
  .subscribe(
    data => this.randomQuote = data,
    err => this.logError(err),
    () => console.log('Random Quote Complete')
  );

...
```

Another benefit of observables is that they can be cancelled. This can be useful for situations where HTTP requests are going on for a long time, perhaps to an unresponsive server somewhere. This is something that isn't easily done with promises, and something that the [Fetch API has yet to implement](https://github.com/whatwg/fetch/issues/27).


## Aside: Using Angular with Auth0

Auth0 issues [JSON Web Tokens](http://jwt.io) on every login for your users. This means that you can have a solid [identity infrastructure](https://auth0.com/docs/identityproviders), including [single sign-on](https://auth0.com/docs/sso/single-sign-on), user management, support for social identity providers (Facebook, Github, Twitter, etc.), enterprise identity providers (Active Directory, LDAP, SAML, etc.) and your own database of users with just a few lines of code. We implemented a tight integration with Angular 1. Angular 2 integration is coming as soon as it's on Beta! You can read the [documentation here](https://auth0.com/docs/client-platforms/angularjs) or you can checkout the [SDK on Github](https://github.com/auth0/auth0-angular).

<img src="https://images.ctfassets.net/23aumh6u8s0i/2rne3k2iZ3EtRRpLuafLhM/67acd166eb2dcacba5d573863f1b0b06/angular-and-auth0" style="border: 1px solid #ccc;padding: 10px;"/>

## Wrapping Up

**HTTP requests in Angular 2** definitely look different than they did in Angular 1.x, but with the change comes a big boost in capability. Having requests return observables is great because we will be able to use RxJS's operators to get the returned streams behave the way we like. We'll be able to use operators like `retry` to automatically start a request again if there are network issues.

In this tutorial we saw how Http can be used to make `GET` and `POST` requests, but we can also use other HTTP verbs like `PUT`, `DELETE`, and `PATCH`. We also saw how we can customize the headers we send with the `Headers` class.

As with Angular 2 in general, Http is always going through changes. The Angular team keeps a very good [backlog of Http issues and feature implementations](https://github.com/angular/angular/issues/2793), which is a good place to keep updated on how Http progresses.


Using Angular $Http and Angular 2 Http - Angular 2 Series Part 3

How the service registry works in a microservice-based architecture



In this post in the microservices series we will talk about *the service registry*. In [part 2](https://auth0.com/blog/2015/09/13/an-introduction-to-microservices-part-2-API-gateway/) we discussed the *API gateway*, where we mentioned that services are **registered in a database**. The gateway dispatches requests according to the information contained in that database. Below we will explore how that database is populated and in which way services, clients and the gateway interact with it.

-----

## The service registry
The service registry is a database populated with information on how to dispatch requests to microservice instances. Interactions between the registry and other components can be divided into two groups, each with two subgroups:

1. Interactions between microservices and the registry (registration)
    1. Self-registration
    2. Third-party registration
2. Interactions between clients and the registry (discovery)
    1. Client-side discovery
    2. Server-side discovery

### Registration
Most microservice-based architectures are in constant evolution. Services go up and down as development teams split, improve, deprecate and do their work. Whenever a service endpoint changes, the **registry needs to know about the change**. This is what *registration* is all about: who publishes or updates the information on how to reach each service.

**Self-registration** forces microservices to interact with the registry by themselves. **When a service goes up, it notifies the registry**. The same thing happens when the service goes down. Whatever additional data is required by the registry must be provided by the **service itself**. If you have been following this series, you know that microservices are all about dealing with a *single concern*, so self-registration might seem like an anti-pattern. However, for simple architectures, self-registration might be the right choice.

![Self-registration](https://images.ctfassets.net/23aumh6u8s0i/793utSBFno7ZnfY2JPkHBW/fc270d61c5b71b09820ffb889cdbfc1d/self-registration-diagram)

**Third-party registration** is normally used in the industry. In this case, there is a **process or service that manages all other services**. This process polls or checks in some way which microservice instances are running and it automatically **updates the service registry**. Additional data might be provided in the form of per-service config files (or policy), which the registration process uses to update the database. Third-party registration is commonplace in architectures that use tools such as [Apache ZooKeeper](http://zookeeper.apache.org/) or [Netflix Eureka](https://github.com/Netflix/eureka) and other service managers.

![Third-party-registration](https://images.ctfassets.net/23aumh6u8s0i/1kXBlTgwxs0IHFqGTfwxXL/46d98df79b3262697685eb4c24bb55f8/third-party-registration-diagram)

Third-party registration also provides other benefits. For instance, what happens when a service goes down? A third-party registration service might be configured to provide safe fallbacks for services that fail. Other policies might be implemented for other cases. For instance, the service registry process might be notified of a high-load condition and automatically add a new endpoint by requesting the instantiation of a new microservice-process or VM. As you can imagine, these possibilities are critical for big architectures.

### Discovery
As you can imagine, discovery is the counterpart to registration from the point of view of clients. When a client wants to access a service, it must find out **where the service is located** (and other relevant information to perform the request).

**Client-side discovery** forces clients to **query a discovery service** before performing the actual requests. As happens with *self-registration*, this requires clients to deal with additional concerns other than their main objective. The discovery service may or may not be located behind the API gateway. If it is not located behind the gateway, balancing, authentication and other cross-cutting concerns may need to be re-implemented for the discovery service. Additionally, each client needs to know the fixed endpoint (or endpoints) to contact the discovery service. These are all disadvantages. The one big advantage is not having to code the necessary logic in the gateway system. Study this carefully when picking your discovery method.

![Client-side discovery](https://images.ctfassets.net/23aumh6u8s0i/2IzcnDuO6qsOYF96uP3ron/bdd6cdc6f18ec352928e19f53287f079/client-side-discovery-diagram)

**Server-side discovery** makes the **API gateway handle the discovery** of the right endpoint (or endpoints) for a request. This is normally used in bigger architectures. As all requests are directly sent to the gateway, all the benefits discussed in relation to it apply (see [part 2](https://auth0.com/blog/2015/09/13/an-introduction-to-microservices-part-2-API-gateway/)). The gateway may also implement discovery caching, so that many requests may have lower latencies. The logic behind cache invalidation is specific to an implementation.

<include src="TweetQuote" quoteText="Server-side discovery makes the API gateway handle the discovery of the right endpoint for a request."/>

![Server-side discovery](https://images.ctfassets.net/23aumh6u8s0i/3FHSwwdLeOmBoLV5PvqNUM/07801774d85e25e330c74f01e5716a01/server-side-discovery-diagram)

## Example: A registry service
In [part 2](https://auth0.com/blog/2015/09/13/an-introduction-to-microservices-part-2-API-gateway/) we worked on a simple API gateway implementation. In that example we implemented dynamic dispatching of requests through queries to a service database. In other words, we implemented **server-side discovery**. For this example, we will extend our microservice architecture by working on the **registration** aspect. We will do so in two ways:

1. By providing a simple registration library that any development team can integrate into their microservice to perform **self-registration**.
2. By providing a sample [systemd unit](http://www.freedesktop.org/software/systemd/man/systemd.unit.html) that registers a service during startup or shutdown (**third-party registration** using systemd as a service manager).

> Why systemd? It has become the de-facto service manager in most Linux installations. There are other alternatives for managing your services but all require installation and configuration. For simplicity, we picked the one that comes preinstalled in most distros, and that is systemd.

### A registration library
Our microservice example from previous posts was developed for *node.js*, so our library will be for it as well. Here is the main logic of our library:

```javascript
module.exports.register = function(service, callback) {    
    if(!validateService(service)) {
        callback(new Error("Invalid service"));
    }

    findExisting(service.name, function(err, found) {
        if(found) {
            callback(new Error("Existing service"));
            return;
        }

        var dbService = new Service({
            name: service.name,
            url: service.url,
            endpoints: service.endpoints,
            authorizedRoles: service.authorizedRoles
        });

        dbService.save(function(err) {
            callback(err);
        });
    });
}

module.exports.unregister = function(name, callback) {
    findExisting(name, function(err, found) {
        if(!found) {
            callback(new Error("Service not found"));
            return;
        }

        found.remove(function(err) {
            callback(err);
        });
    });
}
```

Microservices that perform self-registration need to call these functions during startup or shutdown (including abnormal shutdowns). We have integrated this library into our existing microservice example in the following way (set the SELF_REGISTRY variable to any value to enable this function). Startup code:

```javascript
// Standalone server setup
var port = process.env.PORT || 3001;
http.createServer(app).listen(port, function (err) {
    if (err) {
        logger.error(err);
    } else {  
        logger.info('Listening on http://localhost:' + port);

        if(process.env.SELF_REGISTRY) {
            registry.register({
                name: serviceName,
                url: '/tickets',
                endpoints: [ {
                    type: 'http',
                    url: 'http://127.0.0.1:' + port + '/tickets'
                } ],
                authorizedRoles: ['tickets-query']
            }, function(err) {
                if(err) {
                    logger.error(err);
                    process.exit();
                }
            });
        }
    }
});
```

And shutdown code:

```javascript
function exitHandler() {
    if(process.env.SELF_REGISTRY) {
        registry.unregister(serviceName, function(err) {
            if(err) {
                logger.error(err);
            }
            process.exit();
        });
    } else {
        process.exit();
    }
}

process.on('exit', exitHandler);
process.on('SIGINT', exitHandler);
process.on('SIGTERM', exitHandler);
process.on('uncaughtException', exitHandler);
```

### Third-party registration using systemd
Our gateway example reads service information from a Mongo database. Mongo provides a command-line interface that we can use to register services during startup or shutdown. Here is a sample systemd unit (remember to disable the SELF_REGISTRY environment variable if you are using the sample microservice from this post):

```systemd
[Unit]
Description=Sample tickets query microservice

#Uncomment the following line when not running systemd in user mode
#After=network.target

[Service]
#Uncomment the following line to run the service as a specific user
#User=seba

Environment="MONGO_URL=mongodb://127.0.0.1:27018/test"

ExecStart=/usr/bin/node /home/seba/Projects/Ingadv/Auth0/blog-code/microservices/server.js
ExecStartPost=/usr/bin/mongo --eval 'db.services.insert({"name": "Tickets Query Service", "url": "/tickets", "endpoints": [{"type": "http", "url": "http://127.0.0.1:3001/tickets"}], "authorizedRoles": ["tickets-query"] });' 127.0.0.1:27017/test
ExecStopPost=/usr/bin/mongo --eval 'db.services.remove({"name": "Tickets Query Service"});' 127.0.0.1:27017/test

[Install]
WantedBy=default.target
```

Registration is handled by the *ExecStartPost* and *ExecStopPost* directives by calling the command-line Mongo client (included in all standard MongoDB installations).

Get the [code](https://github.com/auth0/blog-microservices-part3).

## Aside: use Auth0 for your microservices
Auth0 and microservices go hand-in-hand thanks to the magic of [JWT](http://jwt.io/). Check it out:

```javascript
var express = require('express');
var app = express();
var jwt = require('express-jwt');

var jwtCheck = jwt({
  secret: new Buffer('your-auth0-client-secret', 'base64'),
  audience: 'your-auth0-client-id'
});

app.use('/api/path-you-want-to-protect', jwtCheck);

// (...)
```

Your *client id* and *client secret* are available through the Auth0 dashboard. Create a new account and [start hacking](https://auth0.com/docs)!

## Conclusion
The service registry is an essential part of a microservice-based architecture. There are different ways of handling registration and discovery that fit different architectural complexities. Consider the pros and cons described above for each alternative before committing to one. In Part 4 we will study service dependencies in detail and how to manage them efficiently.


An Introduction to Microservices, Part 3: The Service Registry

Learn about Angular 2's new Dependency Injection system and how to use models to organize your app.

---

**TL;DR:** Domain models are important for defining and enforcing business logic in applications and are especially relevant as apps become larger and more people work on them. In this article, we show how this can be done in an Angular 2 app by moving logic out of the component and into a model. We also cover how to inject model classes using Angular 2's new Dependency Injection system. Check out the [repo](https://github.com/auth0/angular2-models-di) for the article to see the code.

This is the second part of our Angular 2 series. You can also check out the first part about [Angular 2 pipes](https://auth0.com/blog/2015/09/03/angular2-series-working-with-pipes/).

---

> Auth0's Angular 2 series brings you tutorials on how to implement the latest features from the framework using the most recent Alpha release at the time of writing.

As applications grow in size, it becomes increasingly important that they be well organized with a solid structure in place. This is especially critical as increasing numbers of developers are added to the team. Application architecture should also strongly focus on the business rules that govern the application and protect sensitive methods from being exposed where they shouldn't be.

<include src="TweetQuote" quoteText="As applications grow in size, it becomes important that they be well organized with a solid structure in place"/>

At the same time, it is important that we keep our applications DRY and maintainable by moving logic out of components themselves and into separate classes that can be called upon. A modular approach such as this makes our app's business logic reusable.  

One way we can achieve this type of structure in Angular 2 applications is by using models to organize our business logic. Whereas the term "model" in Angular has typically been used to refer to the View-Model, what we're discussing here is the domain model-or the set of rules and business logic that an application implements for it to adhere to the organization's needs.

The term "domain model" is, of course, a generic one. Domain models are relevant in any kind of application. In this tutorial, we will see how we can abstract business logic to a model in an Angular 2 app and use the new **Dependency Injection (DI)** system to call upon these models. We will also explore the DI system's features and various ways it can be used.

## Getting Started with an Angular 2 app

We'll be writing our app in TypeScript, but everything will work just fine in ES6. If you'd like an Angular 2 starter app in ES6, checkout [Pawel Kozlowski's](https://twitter.com/pkozlowski_os) [ng2-play](https://github.com/pkozlowski-opensource/ng2-play/) repo.

Our sample app will take a user's details as input and use a model to handle those values. Let's start with a simple component called `UsersAppComponent`.

```js
// app.ts

/// <reference path="typings/_custom.d.ts" />

import {Component, View, bootstrap, bind, FORM_DIRECTIVES} from 'angular2/angular2';
import {Inject} from 'angular2/di';

@Component({
  selector: 'users'
})
@View({
  // Form directives to be used in the template
  directives: [FORM_DIRECTIVES],
  templateUrl: 'userTemplate.html'
})

class UsersAppComponent {

  constructor() {}

}

bootstrap(UsersAppComponent);
```
Our template has some simple inputs for the user to provide their information, including checkboxes for them to select which programming languages they know.

```html
  

  <form role="form" #form="form" (ng-submit)="submit(form.value)">
    
    <input type="text" placeholder="Enter your name" [(ng-model)]="user.name">
    <input type="text" placeholder="Enter your email" [(ng-model)]="user.email">
    <h3>Languages</h3>
    <input type="checkbox" [(ng-model)]="user.javascript">JavaScript
    <input type="checkbox" [(ng-model)]="user.ruby">Ruby
    <input type="checkbox" [(ng-model)]="user.php">PHP
    <button>Submit</button>
  </form>
```

## Handling User Data

For our app, we'll want to take the user's input to see how it can be handled with a model. For simplicity, we'll just log the info to the console in these examples, but you would typically be doing HTTP requests to send the user data off to a server to be persisted.

We could set up a simple `User` class that acts as a model for our data and have some additional methods in our `UsersAppComponent` that act upon the form data. We can do this right within our component, but as will become evident later, there are some drawbacks to this. Let's see what it would look like for now. The class arrangement will be:

![angular2 models dependency injection](https://images.ctfassets.net/23aumh6u8s0i/6o3tJOtNbC96nlsVPqjeLs/a54fc2b4d2955d66f1b84410801b03d6/classes-at-start)

```js
// app.ts

...

class User {
  name: string;
  email: string;
  rating: number;
}

@Component({
  selector: 'users'
})
@View({
  directives: [FORM_DIRECTIVES],
  templateUrl: 'userTemplate.html'
})

class UsersAppComponent {

  // We instantiate the user class.
  user = new User();

  submit(userInfo) {
    // HTTP request would go here
    console.log(
      this.user.name,
      this.user.email,
      this.calculateRating(this.user)
    );
  }

  // Method to calculate the user's points
  calculateRating(userInfo) {
    var rating = 0;
    if(userInfo.javascript) {
      rating += 30;
    }
    if(userInfo.ruby) {
      rating += 20;
    }
    if(userInfo.php) {
      rating += 50;
    }
    return rating;
  }
}

...
```
We have two-way data binding set up on our form inputs, and they are bound to the instance of our `User` model. The `submit` method in our component's constructor logs the all the data to the console, including a calculation for the user's rating that it runs with the `calculateRating` method. How the heck did PHP get to be worth 50 points? I guess we'll never know.

## Improving the Model

While this approach works sufficiently well when an application is small, the way we have set things up does have a few drawbacks:

1. The `User` class isn't enforcing which values should be present or not. This can have implications if some operation downstream expects certain values to always be present.
2. The model doesn't have methods of its own to handle the calculation of the user's rating or the submission of the data. What if we wanted to have this same functionality in another of our app's components? We would need to duplicate the code in those other components.
3. While `calculateRating` is trivial in this example, what if we had some important and sensitive method with business logic that is meant only for specific circumstances? We need a way to be certain that such methods can't be used in places they're not supposed to be.
4. We currently have no ability to potentially share models with a JavaScript backend.

Let's see how we can tackle some of these issues. We'll start by moving the model to its own file. We'll eventually want to end up with classes that look more like this:

![angular2 models dependency injection](https://images.ctfassets.net/23aumh6u8s0i/2AZ4VJnqch6kcfIL6DlYlv/6fc64e402d51f1a5e9c12975324c0ac3/classes-at-end)


```js
// models/user.ts

export class User {
  name: string;
  email: string;
  rating: number;

  constructor(userInfo:any) {
    this.name = userInfo.name;
    this.email = userInfo.email;
    this.rating = this.calculateRating(userInfo);
  }

  private calculateRating(userInfo) {
    var rating = 0;
    if(userInfo.javascript) {
      rating += 30;
    }
    if(userInfo.ruby) {
      rating += 20;
    }
    if(userInfo.php) {
      rating += 50;
    }
    return rating;
  }

  save() {
    // HTTP request would go here
    console.log(this.name, this.email, this.rating);
  }
}
```

We're now using a constructor in our `User` method, which will set the values for `name`, `email`, and `rating` when the class is instantiated. We've got our `calculateRating` method in our class now, along with a `save` method to take care of making an HTTP request to save the data.

In our template, let's switch from using `ng-model` for two-way data binding to `ng-control` to get the form values when the form is submitted.

```html
  
  <form role="form" #form="form" (ng-submit)="submit(form.value)">
    <input type="text" placeholder="Enter your name" ng-control="name">
    <input type="text" placeholder="Enter your email" ng-control="email">
    <input type="checkbox" ng-control="javascript">JavaScript
    <input type="checkbox" ng-control="ruby">Ruby
    <input type="checkbox" ng-control="php">PHP
    <button>Submit</button>
  </form>
```

We can now modify the `UsersAppComponent` to instantiate and save a new instance of the model when the form is submitted.

```js
// app.ts

...

import {User} from 'models/user';

...

class UsersAppComponent {

  submit(userInfo) {

    // Instantiate and save when the form is submitted
    this.user = new User(userInfo);
    this.user.save();

  }
}

...

```

The model and the methods that it relies on are now in the same spot and can be used in other parts of the application as well. In the model, we specified that we want `calculateRating` to be `private`, but as it stands, we would still be able to gain access to it from outside the `User` model. This is part of [TypeScript's design](http://typescript.codeplex.com/discussions/451129), but we can put a workaround in if we really wanted to protect `calculateRating`. Although it might not work as an architectural approach in every situation, we could define `calculateRating` as a function within the class constructor, which would prevent it from being accessed elsewhere. The downside here is that the function is not available to other methods within the class.

```js
// models/user.ts

...

constructor(userInfo:any) {

  this.name = userInfo.name;
  this.email = userInfo.email;
  this.rating = calculateRating(userInfo);

  // Function is only available inside the constructor
  // when the logic really needs to be protected.
  function calculateRating(userInfo) {...}
}

...
```

## Moving to Factories

We've seen how we can instantiate a new model and access methods on it, but what if we wanted to take the factory approach? In this approach, instead of instantiating the model directly in our components, we would call a method like `create` on the factory. As applications grow and classes become increasingly complex, this can have certain advantages, especially for maintainability. For example, if we wanted to change the name of a class that gets instantiated, the factory approach allows us to make a change solely to the factory itself and not all the instantiation points around the app.

This is also where Angular 2's Dependency Injection comes in, as we'll need to inject the factory to make use of it.

```js
// models/userFactory.ts

import {User} from './user';

export class UserFactory {

  // Uses the User model to create a new User
  create(userInfo:any) {
    return new User(userInfo);
  }

}
```

We'll need to inject the `UserFactory` into our component's constructor. Angular 2 comes with an `@Inject` decorator, which is used to attach metadata to the component. We also need to include `UserFactory` in an array when the app is bootstrapped so that it is included as a binding.

```js
// app.ts

...

import {UserFactory} from 'models/userFactory';

...

class UsersAppComponent {
  userName: string;
  userRating: number;
  rating: number;

  // We inject the UserFactory
  constructor(@Inject(UserFactory) UserFactory) {  
    this.UserFactory = UserFactory;
  }

  ...
}

// We bind the UserFactory when the component is bootstrapped
bootstrap(UsersAppComponent, [UserFactory]);

```

With `this.UserFactory` pointing to the `UserFactory`, we can now make use of its methods. Let's adjust the `submit` method to use the factory.

```js
// app.ts

...

submit(userInfo) {
  this.user = this.UserFactory.create(userInfo);
  this.user.save();
}

...


```

Now when the user submits the form, `create` and `save` are called with the form data.

We can also use the model approach to get the data for the user that just submitted the form. For example, we could add a `get` method to the `User` class that returns (or in this case logs to the console) the user's data.

```js
// models/user.ts

...

get() {
  console.log(this.name, this.email, this.rating);
}

...
```

Then within the component we can create a `getUser` method to retrieve it.

```js
// app.ts
...

getUser() {
  this.user.get();
}

...
```

## More on Dependency Injection

We used the `@Inject` decorator to bring in `UserFactory` above; however, TypeScript also allows us to use type annotations, which means the constructor can be written as:

```js
// app.ts

...

constructor(UserFactory: UserFactory) {...}

...
```

The array syntax we used to bind `UserFactory` to our component is the shorthand way of doing it. We can also explicitly state what we want to bind to, which gives us the option of binding to other classes. For example, we could bind `User` to `UserFactory` directly.

```js
// app.ts

...

// The UserFactory can be bound to another name, in this case, User
bootstrap(UsersAppComponent, [bind(User).toClass(UserFactory)]);

...
```

With this, `UserFactory` becomes `User` when used in our component.

## Aside: Using Angular with Auth0

Auth0 issues [JSON Web Tokens](http://jwt.io) on every login for your users. This means that you can have a solid [identity infrastructure](https://auth0.com/docs/identityproviders), including [Single Sign On](https://auth0.com/docs/sso/single-sign-on), User Management, support for Social (Facebook, Github, Twitter, etc.), Enterprise (Active Directory, LDAP, SAML, etc.) and your own database of users with just a few lines of code. We implemented a tight integration with Angular 1. Angular 2 integration is coming as soon as it's on Beta! You can read the [documentation here](https://auth0.com/docs/client-platforms/angularjs) or you can checkout the [SDK on Github](https://github.com/auth0/auth0-angular).

<img src="https://images.ctfassets.net/23aumh6u8s0i/4PnRDegulvaccUIfNyaAtn/8342312355dc6af44a69c07c66f58be7/pub_w_1219_amp_h_559" style="border: 1px solid #ccc;padding: 10px;"/>

## Wrapping Up

It's important that thought be given to how applications are architected so that they are easier to maintain and can be collaborated on by more developers as team sizes grow. It's also important to protect business logic and keep sensitive methods from being accessed outside the class to which they belong. These effects can be achieved by moving logic into models.

Angular 2 gives us a new Dependency Injection system that allows us to inject classes into our components easily. We had a brief look at how the new DI system works, but for a more thorough overview, we recommend you check out [Pascal Precht](https://twitter.com/PascalPrecht)'s post on [Dependency Injection in Angular 2](http://blog.thoughtram.io/angular/2015/05/18/dependency-injection-in-angular-2.html).

Angular 2 Series - Part 2: Domain Models and Dependency Injection

Learn about API gateways and how they work in a microservice-based architecture



In this post in the microservices series we will talk about API gateways and how they can help us solve some important concerns in a microservice-based architecture. We described these and other issues in our [first post](https://auth0.com/blog/2015/09/04/an-introduction-to-microservices-part-1/) in the series.

-----

## What is an API gateway and why use it?

In all service-based architectures there are several concerns that are shared among all (or most) services. A microservice-based architecture is not an exception. As we said in the first post, microservices are developed almost in isolation. Cross-cutting concerns are dealt with by upper layers in the software stack. The API gateway is one of those layers. Here is a list of common concerns handled by API gateways:

- Authentication
- Transport security
- Load-balancing
- Request dispatching (including fault tolerance and service discovery)
- Dependency resolution
- Transport transformations

### Authentication
Most gateways perform some sort of authentication for **each request** (or series of requests). According to **rules** that are specific to each service, the gateway either routes the request to the requested microservice(s) or returns an error code (or less information). Most gateways add authentication information to the request when passing it to the microservice behind them. This allows microservices to implement **user specific logic** whenever required.

### Security
Many gateways function as a single entry point for a public API. In such cases, the **gateways handle transport security** and then dispatch the requests either by using a different secure channel or by removing security constraints that are not necessary inside the internal network. For instance, for a RESTful HTTP API, a gateway may perform **"SSL termination"**: a secure SSL connection is established between the clients and the gateway, and proxied requests are then sent over non-SSL connections to internal services.

<include src="TweetQuote" quoteText="Many gateways function as a single entry point for a public API."/>

### Load-balancing
Under high-load scenarios, gateways can **distribute requests among microservice-instances** according to custom logic. Each service may have specific scaling limitations. Gateways are designed to balance the load by taking these limitations into account. For instance, some services may scale by having multiple instances running under different internal endpoints. Gateways can dispatch requests to these endpoints (or even request the dynamic instantiation of more endpoints) to handle load.

### Request-dispatching
Even under normal-load scenarios, gateways can provide custom logic for dispatching requests. In big architectures, **internal endpoints are added and removed** as teams work or new microservice instances are spawned (due to topology changes, for instance). Gateways may work in tandem with service registration/discovery processes or databases that describe how to dispatch each request. This provides exceptional **flexibility** to development teams. Additionally, **faulty services** can be routed to backup or generic services that allow the request to complete rather than fail completely.

### Dependency resolution
As microservices deal with very specific concerns, some microservice-based architectures tend to become "chatty": to perform useful work, many requests need to be sent to many different services. For convenience and performance reasons, gateways may provide **facades** ("virtual" endpoints) that internally are **routed to many different microservices**.

### Transport transformations
As we learnt in the first post of this series, microservices are usually developed in isolation and development teams have great flexibility in choosing the development platform. This may result in microservices that return data and use transports that are **not convenient for clients** on the other side of the gateway. The gateway must perform the necessary **transformations** so that clients can still communicate with the microservices behind it.

## An API gateway example
Our example is a simple node.js gateway. It handles HTTP requests and forwards them to the appropriate internal endpoints (performing the necessary transformations in transit). It handles the following concerns:

### Authentication
Authentication using **JWT**. A single endpoint handles initial authentication: /login. User details are stored in a Mongo database and access to endpoints is restricted by roles.

```javascript
/*
 * Simple login: returns a JWT if login data is valid.
 */
function doLogin(req, res) {
    getData(req).then(function(data) {
        try {
            var loginData = JSON.parse(data);
            User.findOne({ username: loginData.username }, function(err, user) {
                if(err) {
                    logger.error(err);
                    send401(res);
                    return;
                }

                if(user.password === loginData.password) {
                    var token = jwt.sign({
                        jti: uuid.v4(),
                        roles: user.roles
                    }, secretKey, {
                        subject: user.username,
                        issuer: issuerStr
                    });

                    res.writeHeader(200, {
                        'Content-Length': token.length,
                        'Content-Type': "text/plain"
                    });
                    res.write(token);
                    res.end();                
                } else {
                    send401(res);
                }
            }, 'users');
        } catch(err) {
            logger.error(err);            
            send401(res);
        }
    }, function(err) {
        logger.error(err);            
        send401(res);
    });
}

/*
 * Authentication validation using JWT. Strategy: find existing user.
 */
function validateAuth(data, callback) {
    if(!data) {
        callback(null);
        return;
    }

    data = data.split(" ");
    if(data[0] !== "Bearer" || !data[1]) {
        callback(null);
        return;
    }

    var token = data[1];    
    try {
        var payload = jwt.verify(token, secretKey);
        //Your custom validation logic goes here.
        if(!payload.jti || revokedTokens[payload.jti]) {
            logger.debug('Revoked token, access denied: ' + payload.jti);
            callback(null);
        } else {        
            callback({jwt: payload});                
        }
    } catch(err) {
        logger.error(err);
        callback(null);
    }
}
```

> Disclaimer: the code shown in this post is not production ready. It is used just to show concepts. Don't copy paste it blindly :)

### Transport security
Transport security is handled through **TLS**: all public requests are received first by a reverse nginx proxy setup with sample certificates.

### Load balancing
Load-balancing is handled by **nginx**. See the sample [config](https://github.com/sebadoom/auth0/blob/master/microservices/gateway/nginx.conf).

### Dynamic dispatching, data aggregation and failures
Requests are **dynamically dispatched** according to a configuration stored in a database. Two types of requests are supported: HTTP and AMQP.

Requests also support the **aggregation strategy** for splitting requests among several microservices: a single public endpoint may aggregate data from many different internal endpoints (microservices). All returned data is in JSON format. See this excellent [post by Netflix](http://techblog.netflix.com/2013/01/optimizing-netflix-api.html) on how this strategy helped them achieve better performance. Also check our [post on Falcor](https://auth0.com/blog/2015/08/28/getting-started-with-falcor/) which allows for easy data fetching from many sources.

![Aggregation strategy](https://images.ctfassets.net/23aumh6u8s0i/5czB8vNeCDzOlE0SO9SYif/83a87ab75bd2bbe0a9a7d353ef33613d/aggregation)

**Failed internal requests** are handled by logging the error and returning less information than requested.

```javascript
/*
 * Parses the request and dispatches multiple concurrent requests to each
 * internal endpoint. Results are aggregated and returned.
 */
function serviceDispatch(req, res) {
    var parsedUrl = url.parse(req.url);

    Service.findOne({ url: parsedUrl.pathname }, function(err, service) {
        if(err) {
            logger.error(err);
            send500(res);
            return;
        }

        var authorized = roleCheck(req.context.authPayload.jwt, service);
        if(!authorized) {
            send401(res);
            return;
        }       

        // Fanout all requests to all related endpoints.
        // Results are aggregated (more complex strategies are possible).
        var promises = [];
        service.endpoints.forEach(function(endpoint) {   
            logger.debug(sprintf('Dispatching request from public endpoint ' +
                '%s to internal endpoint %s (%s)',
                req.url, endpoint.url, endpoint.type));

            switch(endpoint.type) {
                case 'http-get':
                case 'http-post':
                    promises.push(httpPromise(req, endpoint.url,
                        endpoint.type === 'http-get'));
                    break;
                case 'amqp':
                    promises.push(amqpPromise(req, endpoint.url));
                    break;
                default:
                    logger.error('Unknown endpoint type: ' + endpoint.type);
            }            
        });

        //Aggregation strategy for multiple endpoints.
        Q.allSettled(promises).then(function(results) {
            var responseData = {};

            results.forEach(function(result) {
                if(result.state === 'fulfilled') {
                    responseData = _.extend(responseData, result.value);
                } else {
                    logger.error(result.reason.message);
                }
            });

            res.setHeader('Content-Type', 'application/json');
            res.end(JSON.stringify(responseData));
        });
    }, 'services');
}
```

### Role checks
```javascript
var User = userDb.model('User', new mongoose.Schema ({
    username: String,
    password: String,
    roles: [ String ]
}));

var Service = servicesDb.model('Service', new mongoose.Schema ({
    name: String,
    url: String,
    endpoints: [ new mongoose.Schema({
        type: String,
        url: String
    }) ],
    authorizedRoles: [ String ]
}));

function roleCheck(jwt_, service) {
    var intersection = _.intersection(jwt_.roles, service.authorizedRoles);
    return intersection.length === service.authorizedRoles.length;
}
```

### Transport and data transformations
**Transport transformations** are performed to convert between HTTP and AMQP requests.

### Logging
**Logging** is centralized: all logs are published to the console and to an internal message-bus. Other services listening on the message-bus can take action according to these logs.

Get the full [code](https://github.com/sebadoom/auth0/tree/master/microservices/gateway).

## Aside: How webtask and Auth0 implement these patterns?

We told you about [webtasks](https://webtask.io) in our first post in the series. As webtasks *are* microservices they too run behind a gateway. The webtasks gateway handles authentication, dynamic-dispatching and centralized logging so that you don't have too.

* For authentication, [Auth0](https://auth0.com) is the issuer of tokens and webtask will verify those tokens. There is a trust relationship between them so that tokens can be verified.
* For real time logging webtask implemented a stateless resilient [ZeroMQ architecture](http://tomasz.janczuk.org/2015/09/from-kafka-to-zeromq-for-log-aggregation.html) which works across the cluster.
* For dynamic-dispatching, there is a custom-built Node.js proxy which uses [CoreOS etcd](https://github.com/coreos/etcd) as a pub-sub mechanism to route webtasks accordingly.

![Webtask](https://images.ctfassets.net/23aumh6u8s0i/26xA1D0RD9OZNmwuVPCCFw/6395ac83c869db331a701848bfa0e59f/webtask)

## Conclusion
API gateways are an essential part of any microservice-based architecture. Cross-cutting concerns such as authentication, load balancing, dependency resolution, data transformations and dynamic request dispatching can be handled in a convenient and generic way. Microservices can then focus on their specific tasks without code-duplication. This results in easier and faster development of each microservice.


API Gateway. An Introduction to Microservices, Part 2

Learn what are microservices and how they are used in the industry



Everybody is talking about microservices. Industry veterans may remember monolithic or SOA-based solutions being *the way* of doing things. Times have changed. New tools have allowed developers to focus on specific problems without adding excessive complexity to deployment or other administrative tasks that are usually associated with isolated services. It has become increasingly easy to choose to work with the right tool for the right problem.

In this **post series**, we will explore the world of microservices, how it can help solve real world problems, and why the industry is increasingly picking it as the standard way of doing things. In this series, we will attempt to tackle common problems related to this approach, and provide convenient and simple examples. By the end of the series, we should have a skeleton implementation of a full microservice-based architecture. Today, we will focus on what microservices are and how they compare to the alternatives. We will also list the problems we plan to discuss in the following posts.

**Update:** in [part 2](https://auth0.com/blog/2015/09/13/an-introduction-to-microservices-part-2-API-gateway/) we talk about the *API gateway*.

-----

## What is a microservice?
A microservice is an **isolated**, **loosely-coupled** unit of development that works on a **single concern**. This is similar to the old "Unix" way of doing things: do one thing, and do it well. Matters such as how to "combine" whatever is provided by the service are left to higher layers or to policy. This usually means that microservices tend to avoid interdependencies: if one microservice has a hard requirement for other microservices, then you should ask yourself if it makes sense to make them all part of the same unit.

<include src="TweetQuote" quoteText="A microservice is an isolated, loosely-coupled unit of development that works on a single concern."/>

![Typical microservices diagram](https://images.ctfassets.net/23aumh6u8s0i/7m1asvRD6piucFe4KV8F0M/c029abc6718f31599e602fdd133c057d/Microservices2)

What makes microservices particularly attractive to development teams is their **independence**. Teams can work on a problem or group of problems on their own. This creates several attractive qualities favored by many developers:

- **Freedom to pick the right tool**: Is that new library or development platform something you always wanted to use? You can (if it's the right tool for the job).
- **Quick iteration**: Was the first version suboptimal? No problem, version 2 can be out the door in no time. Because microservices tend to be small, changes can be implemented relatively quickly.
- **Rewrites are a possibility**: In contrast with monolithic solutions, since microservices are small, rewrites are a possibility. Was the technology stack the wrong pick? No problem, switch to the right alternative.
- **Code quality and readability**: Isolated development units tend to be of higher quality and new developers can get up to speed with the existing code fairly easily.

## Production-quality microservices
Now that we know what microservices are, here is a list of things we need to keep in mind when designing our microservice-based architecture. Don't worry if this seems too abstract; we will deal with all these concerns in a systematic way throughout this series of posts.

- **Cross-cutting concerns** must be implemented in a way such that microservices need not deal with details regarding problems outside their specific scope. For instance, authentication can be implemented as part of any API gateway or proxy.
- **Data sharing** is hard. Microservices tend to favor per-service or per-group databases that can be updated directly. When doing data modeling for your application, notice whether this way of doing things fits your application. For sharing data between databases, it may be necessary to implement an internal process that handles internal updates and transactions between databases. It is possible to share a single database between many microservices; just keep in mind that this may limit your options when and if you need to scale in the future.
- **Availability**: Microservices, by virtue of being isolated and independent, need to be monitored to detect failures as early as possible. In a big software stack, one service that goes down may go unnoticed for some time. Account for this when picking your software stack for managing services.
- **Evolution**: Microservices tend to evolve fast. When dedicated teams deal with specific concerns, new and better solutions are found quickly. Therefore, it is necessary to account for versioning of services. Old versions are usually available as long as there are clients who need to consume data from them. Newer versions are exposed in an application-specific way. For instance, with an HTTP/REST API, the version of the microservice may be part of a custom header, or be embedded in the returned data. Account for this.
- **Automated deployment**: The whole reason that microservices are so convenient nowadays is that it is so easy to deploy a new service from a completely clean environment. See Heroku, Amazon Web Services, [Webtask.io](https://webtask.io) or other PaaS providers. If you are going for your own in-house approach, keep in mind that the complexity of deploying new services or versions of preexisting services is critical to the success of your solution. If deployment is not handled in a convenient, automated way, you risk eventually reaching a level of complexity that outweighs the benefits originally brought about by the approach.
- **Interdependencies**: Keep them to a minimum. There are different ways of dealing with dependencies between services. We will explore them further later in this blog post series. For now, just keep in mind that dependencies are one of the biggest problems with this approach, so seek ways to keep them to a minimum.
- **Transport and data format**: Microservices are fit for any transport and data format; however, they are usually exposed publicly through a RESTful API over HTTP. Any data format fit for your information works. HTTP + JSON is very popular these days, but there is nothing stopping you from using protocol-buffers over AMQP, for instance.

### Doing things right
All of these concerns can be dealt with in a systematic way. We will explore techniques and patterns in this post series to deal with them. Here is what we will be talking about in future posts:

- **API proxying**
- **Logging**
- **Service discovery and registration**
- **Service dependencies**
- **Data sharing and synchronization**
- **Graceful failure**
- **Automated deployment and instantiation**

## Keeping it real: a sample microservice

Now, this should be easy. If microservices take so much baggage off the development team's mind, writing one should be a piece of cake, right? Yes, in a way. While we could write a simple RESTful HTTP service and call that a microservice, in this post we will do it by taking into account some of the things we have listed above (don't worry: in the following posts, we will expand this example to include solutions for ALL the concerns listed above).

For our example, we will pick the backend code from Sandrino Di Mattia's excellent [post](https://auth0.com/blog/2015/08/25/logging-and-debugging-in-react-with-flux-replaying-your-users-actions/) about using Flux for debugging. In Sandrino's post, a simple express.js app makes the backend for a React.js app. We will take that backend and adapt it. You can see the original backend code [here](https://github.com/auth0/react-flux-debug-actions-sample/blob/master/server.js).

The backend in Sandrino's example handles many different concerns: login, authentication, [CORS](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing), update operations over tickets, and queries. For our microservice we will focus on one task: querying tickets. Check it out:

```javascript
var express = require('express');
var morgan = require('morgan');
var http = require('http');
var mongo = require('mongodb').MongoClient;
var winston = require('winston');

// Logging
winston.emitErrs = true;
var logger = new winston.Logger({
    transports: [
        new winston.transports.Console({
            timestamp: true,
            level: 'debug',
            handleExceptions: true,
            json: false,
            colorize: true
        })
    ],
    exitOnError: false
});

logger.stream = {
    write: function(message, encoding){
        logger.debug(message.replace(/\n$/, ''));
    }
};

// Express and middlewares
var app = express();
app.use(
    //Log requests
    morgan(':method :url :status :response-time ms - :res[content-length]', {
        stream: logger.stream
    })
);

var db;
if(process.env.MONGO_URL) {
    mongo.connect(process.env.MONGO_URL, null, function(err, db_) {
        if(err) {
            logger.error(err);
        } else {
            db = db_;
        }
    });
}

app.use(function(req, res, next) {    
    if(!db) {
        //Database not connected
        mongo.connect(process.env.MONGO_URL, null, function(err, db_) {
            if(err) {
                logger.error(err);
                res.sendStatus(500);                
            } else {
                db = db_;
                next();
            }
        });
    } else {
        next();
    }    
});

// Actual query
app.get('/tickets', function(req, res, next) {
    var collection = db.collection('tickets');
    collection.find().toArray(function(err, result) {
        if(err) {
            logger.error(err);
            res.sendStatus(500);
            return;
        }
        res.json(result);
    });   
});

// Standalone server setup
var port = process.env.PORT || 3001;
http.createServer(app).listen(port, function (err) {
  if (err) {
    logger.error(err);
  } else {
    logger.info('Listening on http://localhost:' + port);
  }
});
```

- **One thing and one thing only**: Our microservice's single concern is querying for the full list of tickets. Nothing more. Authentication, CORS and other concerns are to be handled by upper layers in our architecture.
- **Logging**: We have kept logging using the 'winston' library. For now we will just log to the console, but in later versions we will push logs in a predefined format to a centralized location for analysis.
- **No dependencies**: Our microservice has no dependencies on other microservices.
- **Easily scaled**: With no dependencies, a separate process, and operating on a single concern our microservice can easily be scaled.
- **Small and readable**: Our microservice is small and readable. New developers can modify or rewrite it in no time.
- **Data sharing**: For now our microservice reads data from its own database. We will explore in future posts what happens when other microservices need to update or create tickets.
- **Registration and failure**: Our microservice stands on its own. In future posts we will explore how to manage service discovery and what you can do in case microservices fail.

Get the [code](https://github.com/sebadoom/auth0/tree/master/microservices/microservice-1).

## Conclusion
Microservices are the new way of doing distributed computing. Advances in deployment and monitoring tools have eased the pain involved in managing many independent services. The benefits are clear: using the right tool for the right problem, and letting teams use their specific know-how to tackle each problem. The hard part is dealing with shared data. Special considerations must be taken into account when dealing with shared data and inter-service dependencies. Data modeling is an essential step in any design, and is even more so in the case of a microservices-based architecture. We will explore other common patterns and practices in detail in the following articles.


An Introduction to Microservices, Part 1

Learn how to implement pipes (formerly known as filters) in your Angular 2 apps

---

**TL;DR:** In this first installment of the Angular 2 series, we take a look at **pipes** which replace filters from Angular 1.x. Many of the filters from Angular 1.x carry over to pipes, but we also get some new ones. Check out [the repo](https://github.com/auth0/angular2-pipes) for this tutorial to see the pipes in action and to learn how to create your own custom pipes. To see an example of a full Angular 2 app, read Auth0's tutorial on [creating your first Angular 2 app](https://auth0.com/blog/2015/05/14/creating-your-first-real-world-angular-2-app-from-authentication-to-calling-an-api-and-everything-in-between/).

---

> Auth0's Angular 2 series brings you tutorials on how to implement the latest features from the framework using the most recent Alpha release at the time of writing.

## From Filters to Pipes

AngularJS 1.x filters are helpful for formatting output in our templates. With Angular 2, we get this same great feature, but they are now called **pipes**. At the time of this writing, Angular 1.x and Angular 2 have an equal number of filters to pipes, but there isn't direct crossover. The following table shows a comparison:

<table class="table">
<thead>
<tr>
<th> Filter/Pipe Name </th>
<th style="text-align:center;"> Angular 1.x </th>
<th style="text-align:center;"> Angular 2 </th>
</tr>
</thead>
<tbody>
<tr>
<td> currency         </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;"> ✓  </td>
</tr>
<tr>
<td> date             </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;"> ✓  </td>
</tr>
<tr>
<td> uppercase        </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;"> ✓  </td>
</tr>
<tr>
<td> json             </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;"> ✓  </td>
</tr>
<tr>
<td> limitTo          </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;"> ✓  </td>
</tr>
<tr>
<td> lowercase        </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;"> ✓  </td>
</tr>
<tr>
<td> number           </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;">           </td>
</tr>
<tr>
<td> orderBy          </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;">           </td>
</tr>
<tr>
<td> filter           </td>
<td style="text-align:center;"> ✓    </td>
<td style="text-align:center;">           </td>
</tr>
<tr>
<td> async            </td>
<td style="text-align:center;">             </td>
<td style="text-align:center;"> ✓  </td>
</tr>
<tr>
<td> decimal          </td>
<td style="text-align:center;">             </td>
<td style="text-align:center;"> ✓  </td>
</tr>
<tr>
<td> percent          </td>
<td style="text-align:center;">             </td>
<td style="text-align:center;"> ✓  </td>
</tr>
</tbody>
</table>

In this article, we will explore the features provided by some of Angular 2's pipes that aren't comparable to Angular 1.x filters. We'll also learn how to create a custom pipe and use it in our templates.

You'll need to have an Angular 2 sandbox set up for this tutorial. A good one to get started with is [ng2-play](https://github.com/pkozlowski-opensource/ng2-play) by [Pawel Kozlowski](https://twitter.com/pkozlowski_os).

## Basic Pipes

Many of the pipes provided by Angular 2 will be familiar if you've worked with filters in Angular 1.x. Pipes are accessed in our templates in the same way that filters were--with the "pipe" character `|`. For example, we can use the `date` pipe to transform a date object in any way we like by providing it with an argument for formatting:

```js
// app.ts

/// <reference path="typings/angular2/angular2.d.ts" />

import {Component, View, bootstrap} from 'angular2/angular2';

@Component({
  selector: 'pipes'
})
@View({
  templateUrl: 'pipesTemplate.html'
})
// Component controller
class PipesAppComponent {
  date: Date;

  constructor() {
    this.date = new Date();
  }
}

bootstrap(PipesAppComponent);
```

We pointed our `@View` decorator to a `templateUrl` in which we make use of the `date` pipe:

```html
  
  <h1>Dates</h1>
  
  <p>{{ "{{date | date:'mediumDate'" }}}}</p>
  
  <p>{{ "{{date | date:'yMMMMd'" }}}}</p>
  
  <p>{{ "{{date | date:'shortTime'" }}}}</p>
```

![angular2](https://images.ctfassets.net/23aumh6u8s0i/37BF7NE33IEQ0xMA2lAHlk/8ab9d0d3f3f2d9be6ccb3cc8f602f2ae/angular2-pipes-1-1)

## New Pipes

The `decimal` and `percent` pipes are new in Angular 2. These take an argument that describes the "digit info" that should be used--that is, how many integer and fraction digits the number should be formatted with. The argument we pass for formatting follows this pattern: `{minIntegerDigits}.{minFractionDigits}-{maxFractionDigits}`.

**Note:** The `decimal` pipe is accessed using `number` in our templates.

```js
// app.ts

...

@View({
  templateUrl: 'pipesTemplate.html'
})

class PipesAppComponent {
  grade: number;
  rating: number;

  constructor() {
    this.grade = 0.99;
    this.rating = 9.1243;
  }
}

...
```

```html
  <h1>Decimals/Percentages</h1>
  
  <p>{{ "{{grade | percent:'.2'" }}}}</p>
  
  <p>{{ "{{rating | number:'2.1-2'" }}}}</p>
```
![angular2](https://images.ctfassets.net/23aumh6u8s0i/4XFENZUIJ6yoSfLSPVdEJt/e69dc9dc5ab1824a6ef9c193d2215124/angular2-pipes-1-2)

## The Async Pipe

Angular 2 provides a special pipe known as `async`, which allows us to bind our templates directly to values that arrive asynchronously. This ability is great for working with promises and observables. To see how this works, we'll create a simple promise and have it resolve with a string.

<include src="TweetQuote" quoteText="Angular 2's async allows us to bind our templates directly to values that arrive asynchronously"/>

```js
// app.ts

...

@Component({
  selector: 'pipes',
  changeDetection: 'ON_PUSH'
})
@View({
  templateUrl: 'pipesTemplate.html',
})

class PipesAppComponent {
  promise: Promise;

  constructor() {
    this.promise = new Promise(function(resolve, reject) {
      setTimeout(function() {
        resolve("Hey, I'm from a promise.");
      }, 2000)
    });
  }
}

...
```

```html
  
  <h1>Async</h1>
  <p>{{ "{{ promise | async" }}}}</p>

```

After a 2 second delay, the value from the resolved promise will be displayed on the screen.

![angular2](https://images.ctfassets.net/23aumh6u8s0i/5TsNZysQufm6z3ja3Fb7vA/e349949ba860e421ab91e22207fbcf35/angular2-pipes-1-3)


## Custom Pipes

Before Alpha 35, we had to configure our custom pipes with a `pipes` object. However, we can now define a pipe with the decorator `@Pipe` and use it by adding a `pipes` property to the `@View` decorator with the name of the pipe class. This makes it easier and more convenient to register our custom pipes.

```js
// app.ts

import {Component, View, bootstrap, Pipe, PipeTransform} from 'angular2/angular2';

...

// We use the @Pipe decorator to register the name of the pipe
@Pipe({
  name: 'tempConvert'
})
// The work of the pipe is handled in the tranform method with our pipe's class
class TempConvertPipe implements PipeTransform {
  transform(value: number, args: any[]) {
    if(value && !isNaN(value) && args[0] === 'celsius') {
      var temp = (value - 32) * 5/9;
      var places = args[1];
      return temp.toFixed(places) + ' C';       
    }

    return;
  }
}

...

@View({
  templateUrl: 'pipesTemplate.html',

  // We can pass the pipe class name into the pipes key to make it usable in our views
  pipes: [TempConvertPipe]
})

class PipesAppComponent {
  temperature: number;

  constructor() {
    this.temperature = 85;
  }
}
```

```html
  <h1>Custom Pipes - Convert Temperature</h1>
  
  <h3>Fahrenheit: {{ "{{temperature + ' F'" }}}}</h3>
  
  <h3>Celsius: {{ "{{temperature | tempConvert:'celsius':1" }}}}</h3>
```
We use the `transform` method to do any logic necessary to convert the `value` that is being passed in. We can get ahold of the arguments array as the second parameter and pass in as many as we like from the template. As you can see here, we check the type of conversion that we want (e.g., Fahrenheit to Celsius), convert the `value` passed in, and then return the converted value to the number of decimal places specified in the second argument of the pipe.

As mentioned above, we need to provide an array to the `pipes` property in the `@View` decorator to use the new pipe.

![angular2](https://images.ctfassets.net/23aumh6u8s0i/4CierHg40QFc5hYSp4qlCl/9354d43b0c97946d05ac5a032c5b5f9e/angular2-pipes-1-4)

## Aside: Using Angular with Auth0

Auth0 issues [JSON Web Tokens](http://jwt.io) on every login for your users. This means that you can have a solid [identity infrastructure](https://auth0.com/docs/identityproviders), including [Single Sign On](https://auth0.com/docs/sso/single-sign-on), User Management, support for Social (Facebook, Github, Twitter, etc.), Enterprise (Active Directory, LDAP, SAML, etc.) and your own database of users with just a few lines of code. We implemented a tight integration with Angular 1. Angular 2 integration is coming as soon as it's on Beta! You can read the [documentation here](https://auth0.com/docs/client-platforms/angularjs) or you can checkout the [SDK on Github](https://github.com/auth0/auth0-angular).

<img src="https://images.ctfassets.net/23aumh6u8s0i/4PnRDegulvaccUIfNyaAtn/8342312355dc6af44a69c07c66f58be7/pub_w_1219_amp_h_559" style="border: 1px solid #ccc;padding: 10px;"/>

## Wrapping Up

Angular 2 provides some great pipes that carry over well from the filters we are used to in Angular 1.x. We also get some new pipes that give us special functionality, such as the `async` pipe, which binds our templates to asynchronous resources. It's also easy to create our own pipes via the `@Pipe` decorator and the `pipes` key in our `@View` decorators.

You can find the code for this tutorial on [GitHub](https://github.com/auth0/angular2-pipes).

"post-series"