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

Learn how to use roles in your Blazor Server and WebAssembly applications to implement the RBAC authorization model.

Role-Based Access Control in Blazor Applications

How to use the new user-jwts tool to test a protected ASP.NET Core Web API without involving an authorization server.

Test Authorization in ASP.NET Core Web APIs With the user-jwts Tool

matthew-casperson

Technology enthusiast since my first C64. I love writing about new ideas and working with great people.

Product Manager at Octopus Deploy

Matthew Casperson

Learn how to integrate a browser client to reactive streams published by a Spring WebFlux server.

Reactive Streams with Kotlin, Webflux, and rsocket-js

Learn how to create real-time web applications by using the Server-Sent Events specification.

Developing Real-Time Web Applications with Server-Sent Events

avatar

Jared has worked alongside founding teams to define and deliver products which are critical to Fortune 500 enterprises and small businesses, enjoyed by consumers, and depended on by developers. Along the way, he's helped grow multiple companies from a handful of people to hundreds of employees, financial stability, and successful acquisitions. Additionally, Jared is an active contributor to open source software. He is the lead developer of Passport.js, the popular authentication framework for Node.js. Downloaded over 2 million times per month, it powers authentication for innumerable applications on the Internet. He has a portfolio of over 300 repositories freely available on GitHub.

Former Auth0 Employee

Jared Hanson

From basic website authentication to implementing an OpenID Connect server and API authentication: This article covers 3 IAM examples to support your Digital Transformation.



**TL;DR:** We recently [hosted a webinar](https://resources.auth0.com/webinars/3-iam-examples/) that covered modern identity management and what it takes to implement both Authentication and Authorization to support your Digital Transformation. In this article, we'll cover these implementations ranging from basic authentication, to an OpenID Connect server, and API authentication.


## Introduction
Identity and Access Management (IAM) encompasses the security protocols and processes that allow the correct users to access the correct content, at the correct times.  Cloud-based IAM providers, such as _Auth0_, have created simpler and more intuitive ways of managing user access, and they form an important part of **digital transformations.**

<include src="TweetQuote" quoteText="Identity and Access Management (IAM) is the security and process that allows the correct users to access the correct content, at the correct times."/>

Digital transformation, for those unaware, is not just a buzzword. It encapsulates the process of heavily utilizing modern, digital technologies to radically change businesses.

> Look beyond the hype and you'll find a daunting task at the heart of digital transformation. Rather than focusing on any single IT project, digital transformation describes a series of projects that, together, change every facet of an organization, from back office operations to customer interactions, often with the end goal of making these different processes intrinsically linked.

[http://www.itpro.co.uk/strategy/28047/what-is-digital-transformation](http://www.itpro.co.uk/strategy/28047/what-is-digital-transformation)

As we go through this article, we will cover three _IAM_ use cases. Firstly, we will cover implementing authentication on a basic website. This is the situation most people will find themselves in and the most common use case of the three. Once we've covered basic website authentication, we will move onto standard federated logins.

The second scenario we will cover is _**Enterprise SSO**_. We shall create a fake example company named _Acme,_ whos enterprise customers demand a way of logging into Acme's various services without having to remember a range of username and passwords. By using OpenID Connect, we will show how they can allow their customers' employees to log in with corporate credentials.

Finally, we will cover API integration. When we want to allow our customers to integrate our service into their line-of-business applications in custom ways.


## A Basic Website
Something we're all familiar with is the basic user registration and login that we find on our favorite websites. To access various areas and features of most websites, we usually have to create an account with them. From a high level, all this consists of is a database containing our usernames/email addresses and a complex hash of our passwords (hopefully).  Throughout this article, we'll use an example data model in which crucially, the core Users table will never change the schema, only the data references will change. The basic data model looks like this:

![Basic Data Model](https://images.ctfassets.net/23aumh6u8s0i/74wMh29yR35x1gyeASUrmv/9e037c843a6ff03b59be3420a7945677/basic-data-model)

Our sample data model is that of a simple project management tool, in which Users own Projects. Very basic. Now, what we need is a way for our users to register their details for our application.

![Basic Registration](https://images.ctfassets.net/23aumh6u8s0i/3L7FmaYEjSOGrUdOexyRdw/9e8c66dd6e21383e06694f5db8490da6/basic-registration)

As you can see in the image, our app now contains a standard sign up for new users to register for our service. From a back end perspective, the form uses a `POST` action to submit the form data to our `/signup` resource. Our back end then writes this data to our chosen database and forwards the user onto the specified route upon successful completion. Once we have a user signup implemented, a user login is the next thing we need to address. The basic login flow for our simple web app looks like this:

![Basic Login](https://images.ctfassets.net/23aumh6u8s0i/1Ku7YSRGdgbf5xOoEpUnxQ/55c563b1aaa309b085de6fcfa8a72b6f/basic-login)

In our login flow, users submit their email address and password, which issues a `POST` request to our `/login` resource. Our application back end takes the credentials supplied, issues a database lookup and ensures the details are correct. If so, our app will issue a HTTP forward request onto the specified resource, containing a Session Cookie.

In the image above, you can see that the Session Cookie is set as a HTTP Header, and is actually the most important factor in this flow. The Cookie will contain tokenized information about our users perhaps including metadata such as the user's name and avatar, so as to reduce database hits going through our web app. Besides containing the user's metadata, the Session Cookie is (more importantly) also the authorization credential for all subsequent requests as the user browses our application.

With this implemented, our application now has a basic user authentication system set up. Being basic, there are many features that we haven't addressed here, but that would really need implementing. Password hashing, password complexity verification, password reset functionality, and multi-factor authentication to name a few. Luckily, by using a system such as [Auth0's Hosted Login](https://auth0.com/docs/hosted-pages/login), we save the worry of having to implement these, as they come as standard. Out of the box, Auth0 offer the features mentioned above plus many more. You can have a fully functional user management system setup in minutes.


## Single Sign On (SSO) for Enterprise
If you've used services such as Amazon Web Services, Slack, GitHub or Salesforce, you will notice that they all have a Single Sign On (SSO) implementation so that users can access those services with their corporate credentials. As we add SSO federated capabilities into our sample application, we do have one constraint in that (as mentioned above), we do not want to change the data table schema.

![SSO Data Model](https://images.ctfassets.net/23aumh6u8s0i/6M9ZrX0pYtMQlLySKJ7j0r/fd0e804720e293fda0d1c9c2f1026740/sso-data-model)

Our `Users` and `Projects` tables do not change, but the relationships evolve to include our external identity providers.

For our Federated SSO implementation, we're going to implement an _Identifier-first_ login prompt. Our application will only ask for an email address for the user:

![SSO Login Prompt](https://images.ctfassets.net/23aumh6u8s0i/5uaqLWmRI3n3Z0TKysWTcg/dfb0e87190ced85da967c708cb216f31/sso-login-prompt)

The point of this is to look up the SSO identity provider associated with this email address, which in this case is **_cotoso.com_**, so the user will be redirected there to log in.

![SSO Flow](https://images.ctfassets.net/23aumh6u8s0i/4ovSoo6JhxjhQnaDBYNRcv/b1a5209e2608147b29e1cfd70fe7b5cc/sso-flow)

As shown in the image above:  once the user _(sally@contoso.com)_ enters her email address, our application determines that _contoso.com_ is our Identity Provider and redirects her there. Sally then logs into her _contoso.com_ corporate account, and _contoso.com_ verifies it. She is then redirected back to our application with access granted.

As part of this OpenID Connect authentication response, the `code` returned in the OpenID Connect Auth Response above is exchanged for an `ID Token`. The `ID Token` is what conveys the identity information from _contoso.com_ to our application, and looks like this:

``` json
{
  "iss": "https://id.contoso.com",
  "sub": "2482899761001",
  "name": "Sally",
  "email": "sally@contoso.com"
}
```

As with all ID Tokens, there is an _Issuer_ and an _Identifier_.  The Issuer being `https://id.contoso.com`, and the _Identifier_ being the subject `"sub": "2482899761001"`. In the auth flow above, our application (acme.com) will now look at this ID Token, identify Sally, and forward her onto our Dashboard, setting a Session Cookie for future requests.

From a database point-of-view, this SSO flow will look like this:

![SSO Database Flow](https://images.ctfassets.net/23aumh6u8s0i/3l5n9ubTlVC3BL9zbbmZJe/7d8aeb7f309d3477d96a3313d9b47748/sso-database-flow)

Firstly, our application will perform a lookup for the identity provider _contoso.com_, and redirect Sally to that login. Once Sally has logged in on _contoso.com_ and has been redirected back to our application, one of two things will happen. If Sally has never registered with our application before, a User record will be created for her, with the information returned from _contoso.com_. This would replace the sign up step we implemented in the basic example above. Our application will then associate the external identity with the new user record for find operations on subsequent logins.

![SSO Final Step](https://images.ctfassets.net/23aumh6u8s0i/20d076SSRPax813EDFIfYO/3f23fac0b59109b8a9d04c8a68faeb46/sso-final-step)

Similar to our earlier basic example, upon successful login, a _Session Cookie_ is set to portray the information required for subsequent requests.

With the above, we now have Single Sign On implemented on our acme.com sample application. Worth noting here is that in this SSO implementation, we have chosen an identifier-first login prompt with no option for a password. In reality, we would need to implement a password option for users that have existing non-federated accounts. Beside this, we should also implement a SAML integration, and support for account linking an unlinking.

By choosing to use an IDaaS provider like _Auth0_, we can get all of these features, plus many more straight out of the box.  Using [Auth0 for SSO](https://auth0.com/single-sign-on) allows us configuration of any enterprise connection, including Active Directory, LDAP, ADFS, SAML, and more with just a few lines of code.


## API Authorization
For the final implementation example of this article, we're going to look at API Authorization. We need to implement API auth so that our customers can integrate our service into their applications in ways not offered as standard, and to allow them deeper integrations. Once again, let's take a look at our data model, now including API auth:

![API Auth Model](https://images.ctfassets.net/23aumh6u8s0i/4NRyLQsRvkuyFmq64xuNeN/d0b5238abf314ac3f4051da5db971a17/api-auth-model)

Although the model now looks slightly more complex, following our aforementioned constraint; our `Users` and `Projects` schemas have not been changed. The schemas for SSO providers have not changed either. What has changed are the tables on the left, which introduce support for other people getting access to _Acme's_ APIs. If you are familiar with Facebook sign-on or GitHub etc, the terms above are fairly typical. `Clients` are the applications a user may build/use to access APIs and services, `Resource Servers` are the APIs themselves, and the Authorization Grants `(AuthZ Grants)` track the permissions that have been granted between the users and the applications.

For our API Authorization example, we are going to imagine that our sample company (Acme.com) have a customer named _Fabrikam.com,_ who wish to allow their customers to pull a list of their `Projects` from the _Acme_ API to display on their own dashboard.

From a simple button on the _Fabrikam.com_ website, their customers will be redirected through an OAuth2 Authorization request to the _Acme_ website, returning an Auth code on successful submission. Using the OAuth2 auth flow of [Client Credentials Grant](https://auth0.com/docs/api-auth/tutorials/client-credentials), this Auth code will then be swapped for an **Access Token** and used in the web application's _Authorization Header_ using the `Bearer` protocol.

Let's take a look at how the API Auth flow works visually:

![API Auth Login](https://images.ctfassets.net/23aumh6u8s0i/49pbvFGduF9VwuFevWGf66/e5c9bc8dc3632dbb826ff32e02b5cb46/api-auth-login)

As you can see from the image above, the customer of _Fabrikam.com_ clicks on the 'Connect to Acme' button on their Dashboard.  This click then issues a GET request to the `/connect/acme` route, which from the back end initiates an OAuth2 request to the _Acme.com_ server. The _Fabrikam.com_ customer is then prompted to log in using their _Acme_ credentials. On success, the _Acme.com_ server issues the OAuth2 Authorization Response to the `callback_url` specified in the initial request. In a similar manner to the _OpenID Connect_ example above, this response contains a `code` that will be exchanged for an **Access Token:**

![API Auth Login Response](https://images.ctfassets.net/23aumh6u8s0i/36WBGudxJpP0g6U9RaRb32/0dfc5f2e368f90c40054592d672aabcb/api-auth-login-response)

Following the [Client Credentials Grant flow](https://auth0.com/docs/api-auth/tutorials/client-credentials), the _Fabrikam.com_ back end swaps the above code for the Access Token needed for subsequent API requests.  The Access Token returned will have the following appearance:

``` json
access_token = eYJ0eXAi0...

{
  "iss": "https://www.acme.com",
  "aud": "https://api.acme.com/v1/",
  "sub": "501",
  "scp": [ "read:projects" ]
}
```

This _Access Token_ is similar to the _ID Token_ shown in the previous example, but instead of just identifying the user, it is also responsible for allowing _Fabrikam_ to make API calls subsequent to this Authentication event happening. This Token contains _Acme_ as the issuer, the API route to be used, the `subject` referring to the user id of "502", and the request _permissions_ in the `scope`. With the _Access Token_ now available to _Fabrikam.com_, it is used with requests for the customer's `Projects` from the _Acme.com_ API.

![API Auth Authd Reqs](https://images.ctfassets.net/23aumh6u8s0i/59HhtjSyKjTQST9ItgwwoL/8e3d373768fb5cfcb94297f2395ff731/api-auth-authd-reqs)

As the image shows, _Fabrikam_ sends the encoded token in the `Authorization` Header of the request, using the `Bearer` protocol, in all subsequent API requests.  The _Acme.com_ API successfully returns the customer's `Projects` which are listed in the Dashboard, as shown. That brings to a close the OAuth2 Client Credentials grant for API Auth example. However, we can take this a step further still. What if we wanted to combine this API Auth with the Enterprise SSO implementation in our previous example?

There may arise a scenario in which  _Fabrikam.com_ want to integrate with _Acme's_ APIs, but a user at _Acme_ authenticates with corporate credentials for _Contoso.com_ (who is an enterprise customer) as within our previous example. The flow becomes a multi-step process, with the first request coming from _Fabrikam_ to _Acme_, then _Acme_ to _Contoso_, with the responses flowing back in the opposite direction, back to _Fabrikam._. The interesting point of this scenario is that _Acme_ is acting as both an Identity Provider (when providing API authorization), and a Relying Party (when it's consuming identity information). This pattern may sound complex, but it is a very common scenario. Most SaaS companies both provide services, as well as authenticating users from other companies, meaning they have to implement both sides of the protocol (client and provider). The following diagram shows this implementation layout:

![OAuth OpenID Combine](https://images.ctfassets.net/23aumh6u8s0i/6WZAjqTn3OMo2eRyuLgvCS/1d678ed2c67c51061ddb1dfbb8773e90/oauth-openid-combine)

<include src="TweetQuote" quoteText="OAuth 2.0 and OpenID Connect have the same protocols because OpenID Connect is just an extension of OAuth."/>

Happily, as you will have noticed throughout this article, OAuth 2.0 and OpenID Connect have the same protocols, because OpenID Connect is just an extension of OAuth. This saves us a lot of hassle on implementation. At this point, with Authentication becoming a more prominent feature, it might be worth setting up a single, centralized server to handle all of the Auth requests coming through our app _(Acme)_.

If we revisit our data model, we can see that all of the tables in our model, except for the `Projects` table, can be treated as a separate concern, and become our authentication server:

![API Auth Model Pattern](https://images.ctfassets.net/23aumh6u8s0i/6jcNbD9NpTsH1E5Z9JcNtL/fd08c21e843f5af8e3944886aa3047af/api-auth-model-pattern)

We can take advantage of this in our architecture by creating the aforementioned centralized Auth server on a subdomain such as `id.acme.com`, and piping all of our Authorization / Authentication requests through there. The applications authenticating and being granted authorization through this centralized server may be third-party applications, such as _Fabrikam.com_ or _Contoso.com_, but also internal applications such as `app.acme.com`. Setting up this single centralized server is a nice and clean way to solve a lot of Auth challenges, with a single protocol and a single implementation. The architecture for this server could look like the following:

![Centralized Auth Server](https://images.ctfassets.net/23aumh6u8s0i/2hj6ZSI6wVtHmguWHPlEHq/8180c2f0e4abff657db1f05cb9536ecb/centralised-auth-server)

So with this, we have a fully functional OAuth 2.0 server implementation. Whilst this implementation is entirely functional, there are a few extra features not included in this example, that you would want to implement in the real world. One of the biggest is a _Consent Prompt_ ensuring users have the options of granting the application access, such as the following:

![OAuth2.0 Consent Prompt](https://images.ctfassets.net/23aumh6u8s0i/71FwyIRzi8zepAO1e0g4fu/388e0dfbe33ab932a3467b5e7fc3b142/consent-screen)

Besides this, consent and token revocation is also a must-have feature that would need implementing. Lastly, token introspection and JWTs for stateless authorization are both desirable features one would ideally implement.

If you wanted a fully-featured OAuth 2.0 server with all of the functionality mentioned above, it is definitely worth checking out an IDaaS provider to save you all of the implementation hassles. [Auth0](https://auth0.com/docs/protocols/oauth2) offers out of the box, fully featured OAuth 2.0 implementations that take care of all of the architecture above, plus offer more features and functionality; and all implemented without having to build and manage it yourself.



<include src="asides/AboutAuth0" />


3 IAM Examples to Support Digital Transformation

auziros:bobby-johnson

Bobby is a full-stack developer, advocate, and evangelist at Auth0. He is a passionate engineer with an interest in learning and teaching new technologies, using open source software, and engaging the greater software development community. His experience ranges from building line-of-business applications for financial professionals with Russell Investments and Milliman to distributed social content apps with Cheezeburger and Steller.

Developer Advocate Engineer

Bobby Johnson

Webhooks are a clean and simple way to add extensibility points into your SaaS, but Serverless Extensibility removes several points of friction on your customers.



So you have shipped your first SaaS and customers are beating down your door to sign up and hand you buckets of money. Your code is tight. Your servers are humming. The venture capitalists are talking IPO. Everything's coming up roses.

Then it starts; Some customers want complex data flow logic added, others want instant notifications via SMS for each order placed, and then there is a host of other SaaS systems they all want you to integrate with.

How do you handle these requirements? You obviously can't do them all, so you have to choose, meaning some customers will be left unsatisfied and possibly move off your product. Beyond that, there is a different problem. Any work that you decide to do for these one-offs takes away from focusing on your core value proposition, and adds additional maintenance and supports costs.

This problem is, of course, nothing new. Every successful internet service has experienced it in some form since long before web 2.0 was a thing.

## Webhooks Are the Answer!

A common solution is to introduce Webhooks into your platform. They are relatively straightforward to implement; identify the critical extension points of your platform, craft the perfect payload at each point, wire up a subscription administration interface and release it to your customers.

![Webhook Diagram](https://images.ctfassets.net/23aumh6u8s0i/1Cap5PMOy7LJ7NqrCKZ7s7/c42169ef82ce9bec57cb9c34f444ee74/webhook-model)

You don't have to build the customizations. Your engineering team can stay focused on solving the core business for your SaaS.

- You don't have to build the customizations. Your platform can stay tight and focused on solving the business problem it was intended to address.
- You don't have to host the custom logic anymore. The code triggered by the webhook runs completely isolated and secure from your platform and your other customers, dramatically reducing the resources needed to keep your SasS up and running.
- Customers are free to choose any language or technology stack they prefer to process the Webhook payloads.
- You enable other SaaS providers and partners to build integrations with your product to satisfy their customers.

## The Flip Side of Webhooks

Webhooks have effectively allowed you to externalize the customization overload on your platform. What you may not realize is that you have effectively placed that burden directly on your customers.

Mary, who heads IT at one of your customers, a 20 person law firm in Atlanta, did not sign up for this. Your Webhook strategy created a bunch of ongoing work for her and her team.

- She has to figure out how to build the service the Webhook is calling. It needs to be robust and resilient under load.
- She has to find hosting for this service. Heroku and AWS may be great options for this, but Mary may be completely unfamiliar with them.
- She needs to consider security concerns with exposing the service to the internet. Setting up HTTPS is no cakewalk.
- On top of all this, she needs to find a monitoring solution that will alert her to outages or problems, not to mention dealing with being on call to address them.

In a big company, this is even more of a challenge. Budgets need to be considered and appropriated. Coordinating between different departments deciding who is going to build it, deploy it and pay for it can become an impediment. Large SaaS products like Salesforce may require engaging an integration team.

All of this contributes to taking longer to deliver the value the customer wanted in the first place.

<include src="TweetQuote" quoteText="Webhooks are deceptively simple on the surface."/>

Webhooks are deceptively simple on the surface. Many platforms offer Webhooks, but consuming them has a high barrier to entry. Your customers need to think carefully about pursuing them. They are committing to the maintenance of that infrastructure for a very long time. All of this contributes to taking longer to deliver the value the customer wanted in the first place.

![Hidden Complexity](https://images.ctfassets.net/23aumh6u8s0i/2QmCGX1FCBJZxRO59tG1F9/6be6268dca75d89775063232fea63cc9/hidden-complexity)

## Serverless Extensibility, Going Beyond Webhooks

A new approach is starting to emerge in the industry, one that we call Serverless Extensibility. Instead of placing the burden on customers, SaaS products can leverage a Serverless platform to allow users to author and execute extensions directly in the product.

![Serverless Extensibility](https://images.ctfassets.net/23aumh6u8s0i/5T68DlpINImq6GgvWXaaAU/a17cb497333e3623376f3b1e92ff0cff/serverless-extensibility)

Users can now create custom extensions within the product using an inline code editor, choosing from a pre-defined selection. At runtime, The SaaS calls out to a Serverless provider to securely execute the code.

Serverless Extensibility makes it much easier and faster to customize your product and get the value to your users. Not only that, but it saves your customers money as they substantially reduce up-front development cost, and they no longer have to deal with ongoing hosting and maintenance. Removing that friction and cost means higher user retention, which our data shows can be as high as 10x.

## Serverless Extensibility in the Wild

### Auth0

Here at Auth0, we have been working on extensibility for a while. We are known for offering the simplest set of tools to solve the most complex identity use cases. With Auth0 Identity, you can easily authenticate and authorize apps and APIs with any identity provider running on any stack, device, or cloud.

For several years customers have been able to execute arbitrary Node.js code during the authorization process using [Rules](https://auth0.com/docs/rules/current). Several templates are available or they can create an empty Rule to customize right in the management dashboard.

Recently, we added [Hooks](https://auth0.com/docs/hooks), allowing users to customize the behavior of Auth0 at credential exchange, or at pre and post user registration extension points.

![Auth0 Hook Editor](https://images.ctfassets.net/23aumh6u8s0i/2giTBcb9fDHDMAQAe4YKjz/c7fcf8b9c7e9ff6b91b836249e7b5d38/hooks-editor2)

Using Auth0's extensibility has enabled our customers to easily customize the product to handle custom business logic and integrate with a variety of 3rd party services.

### Twilio

Twilio is a cloud communications platform that provides building blocks to add messaging, voice, and video to your web and mobile applications.

With Twilio, you can provision a phone number that accepts calls, faxes, MMS or SMS messages. You can quickly respond to the incoming events using TwiML, an XML based message format that allows you to define simple non-interactive responses. For interactivity, you need to configure a Webhook processor that interacts with the Twilio API.

Twilio recently augmented their Webhook based extensibility with [Twilio Functions](https://www.twilio.com/blog/2017/05/introducing-twilio-functions.html). In the introduction presentation at Signal 2017, Carter Rabasa explained the reasoning this way.

> **"The first thing that Twilio tells you to do is download a web application. And then we ask you to go deploy that web application to some server, somewhere."**<br />
> Carter Rabasa - Product Manager @ Twilio

Now you can easily create a function that handles incoming voice calls or messages right in the Twilio console. When saved, the function is deployed to a serverless environment and can now be attached to incoming events.

![Twillio Editor](https://images.ctfassets.net/23aumh6u8s0i/3KldDEc7tzPjEJsYxrOoWy/f81658b330a71432a553f8ff5d3d4f44/twilio-editor)

Using Twilio Functions enables customers to now on board much more quickly to using Twilio's platform, than was previously possible.

### Stamplay

Stamplay is a business automation platform that provides the ability to connect any application, database or service regardless of if data is sitting in the cloud or on-premises.

With Stamplay, you can plug in a large and growing list of integrations and use them to orchestrate communication between systems based on event triggers. It offers a beautiful point-and-click task editor that allows any business professional to wire together interactions.

In January of 2016, Stamplay released Code Blocks, a built-in extensibility point that solved a specific need in their product. Giuliano Lacobelli introduced it this way.

> **"Sometimes you cannot get around the need for some custom code."**<br />
> Giuliano Lacobelli - Co-Founder @ Stamplay

Now Stamplay customers can create custom integrations within the inline editor, and use them directly on Stamplay's drag and drop environment.

![Stamplay Editor](https://images.ctfassets.net/23aumh6u8s0i/46BGeqb2Z8vlohgWhM9wEK/694b8ba3597091badefdc6f8ab2cc502/stamplay-editor2)

Using Stamplay Blocks allows customers to go well beyond the out-of-the-box integrations, providing a stickier experience.

## Summary

Webhooks are a clean and easy way for you to add extensibility points into your SaaS, but they can put an extra ongoing burden on your customers.

Serverless Extensibility removes as much friction as possible, allowing customers to customize the usage of your platform in a secure, scalable, and reliable way that is offered directly in the product.

Removing this friction makes customers stickier to your product, allowing them to focus on their core business and more quickly to deliver value to the market.


Why is Serverless Extensibility better than Webhooks?

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

Up the ante using JavaScript to build a simple web server with a microcontroller.

JavaScript for Microcontrollers and IoT: A Web Server

71fb37b19e60e1b27a78dc91630dbb29

Alex Stanciu

A deep look at how we automated our employee access request system using Auth0 as the directory and Webtask for serverless last mile integration with our systems


## Automating Access Requests & Provisioning
_A deep look at how we automated our employee access request system_

> “Give me access to vpn”

This is all you need to tell our Slack bot; a request is created and your manager receives an approval request.

### Some Background
Granting users access to various resources is a challenge that many (if not most) organizations face. Unfortunately, many small/medium-sized companies find the cost of purchasing and operating monolithic provisioning systems prohibitive. User access often becomes a highly manual and messy process. Here at Auth0 we started out with a Google Form: employees would fill it out checking off various resources/apps they wanted access to. The form saved into a Google Sheet where a script would take each entry and create an Issue in a GitHub repository. Our IT team would then use the repo’s issues as a request tracking system and manually fulfill them.
There are a few problems with this approach:

- No approval mechanism
- No tracking, and no easy way to show what an employee has access to
- Very hard to automate
- Pretty bad UX

… so we decided to build something

## Goals
For our internal MVP, we wanted to at least address the above points, but also set ourselves up so this tool could grow:

- Provide an easy way to define resources (the things that people can request, for example: email distribution lists, building badges, access to AWS, GitHub, laptop, and VPNs, as well as work orders like “restore a backup” or “reset MFA”)
- Customizable, multi-step, dynamic approval workflows 
- Tracking/reporting to help our SOC2 audits
- Mechanism to setup automated fulfillment for things that can be automated (for ex, via APIs, automatically add a user to our GitHub organization)
- Frictionless UX: we are Slack bot junkies, so we knew this was a critical integration
- Architecture that will allow expansion
- Extendable: if someone wants to convert a resource from manual to automated fulfillment, it shouldn’t require changes to the app or redeployment
- Use this opportunity to explore any new technologies we’ve been watching/itching to play with

## End Result
After three months of on-the-side development, we launched our tool, code-named “Phenix” (no, it’s not misspelled).
![Phenix](https://images.ctfassets.net/23aumh6u8s0i/OSpKH5qrnboV0jXDlgCLa/470e00f1b6b8600931670fafb2c4e82b/phenix)

Let’s do a quick walkthrough of the basic flow. In this sample use case we’ll set up a resource to allow employees to request to be added to our Auth0 GitHub organization.

We first create the resource and specify a few options:
![Resource](https://images.ctfassets.net/23aumh6u8s0i/38KDHh0L4DMxsipMk91sR0/8d2e0c553ac793ea8040be78a198f958/resource)

For the rest of the resource, we configure a two-step serial approval workflow that includes Manager Approval and Security Team approval. 

For fulfillment, we’ll keep it manual for now and assign it to the Dev Ops group.

Resources also allow the creation of a custom form to capture data from the user at the time of request. We will use this to capture the user’s GitHub userid and a comment.
![Resource Tabs](https://images.ctfassets.net/23aumh6u8s0i/6AiN6btnQF400oa4L46st8/ef0df67416302a3992117a0d649a6c79/resource-fillout2)

Now that the resource is configured, let’s request it:
![Create Request](https://images.ctfassets.net/23aumh6u8s0i/2pZZRvy3HkZAcRAszzkLpg/9b94bb6c071f47d647b37856d321f6ca/create-request)

## Approvals
The above request will step through each stage of the approval process; if all stages are approved, the request will switch to fulfillment mode. If any stage is rejected, the approval process stops and the request is finished.

We configured an approval stage called Dynamic Approval for the Manager because each requester could have a different manager. We need to determine who the approver is at run-time, when the request is processing. We do this using the webtask platform. Setting the approval type as dynamic allows the creation of a webtask where the end user (the Administrator) can write custom code that figures out who the manager is.
![Dynamic Approval](https://images.ctfassets.net/23aumh6u8s0i/21EreRfb6flPav2l1PWSja/a70c177acb7d0542fef3a79e74d26dca/dynamic-approval)

Clicking Edit opens the webtask editor where we have simple code to retrieve the manager userid from the request beneficiary’s profile:
![Get Manager Webtask](https://images.ctfassets.net/23aumh6u8s0i/53cicumNduufCQTocCB8Tn/dcb98cb627e5b65023f785ab58fa5a89/get-manager-wt)

The manager info is saved in the Auth0 user’s `app_metadata` attribute; this is currently populated via an existing outside script that syncs our HR system with Auth0 profiles. If we didn’t have this data already in Auth0, this code would instead make an API call to our HR system (BambooHR) to get the user’s manager.

When the request is submitted, the approvers receive a ticket in their inbox representing a pending approval task. For the above request, since I am an admin, I will be able to see both approval tickets (for both the manager and security stages). I will approve both and then reject the fulfillment request. Normally these three steps would be performed by separate people
![Inbox - Approve Requests](https://images.ctfassets.net/23aumh6u8s0i/GKun89oDVrTgBWTv8FGyT/a0e9c1090ec562773b5e5bfb4b5db90b/inbox-approve)

We can see the final status of this request as:
![Final Request](https://images.ctfassets.net/23aumh6u8s0i/4GGFuqmQIJPKXRmwMxTY6V/fa3fcaf8755fbcf4b3606d9b692e76ac/final-request)

As you can see, for each stage it correctly shows who the intended approver/fulfiller was and who actually took the action. Great for our audit history!

## Slack
![Slack Approval](https://images.ctfassets.net/23aumh6u8s0i/50eLESbCPEwIhDKpf7ehsc/33dc2a199470066661f6f798aff8b39f/slack-approval)

When the approval tickets are created, the approvers also receive a message in Slack that they can approve or reject. If the approval is set to a group, we can create mappings of groups to Slack channels so only one message is posted in the group’s channel. The system ensures that only designated approvers are allowed to click the buttons (not everyone in the #devops channel is in the DevOps Group). 

We also wanted the ability to create requests from Slack.  This proved to be a bit more challenging in the end, but a ton of fun. 

This is what it looks like:
![Slack Request](https://images.ctfassets.net/23aumh6u8s0i/74iluPGFjW2YgBqKgDSeui/37713e91b29990cb1ac292e0fb5c68d0/create-request-slack)

It may not be immediately evident but there is a lot going on here.

First, the bot needs to keep track of different conversations, with different users, across different Slack teams. This is easy enough, but it also needs to keep track of _where_ in the conversation it is.

It accepts some built-in commands, like `help`, `list`, etc., but if someone says something like, “I need access to vpn”, this is not a built-in command. To make sense of this, we use [api.ai](https://api.ai)’s NLP services to process these kinds of phrases and detect if the user said something that matches making a request:

>“give [_user_] [_resource_]”

>“request [_resource_] for [_user_]”

>“I want access to [_resource_]”

>etc…

Once it detects that the user wants a resource and for whom (you can request things for other people, too), it then looks to see if that resource has a form defined. If so, we start a “conversation” with the user, progressively asking for the data in the form. 

The hard part here was keeping track of it all. With Slack bots, there is no inherent concept of a session, so we had to build this.  The bot could receive a message like “jdoe35” and it would need to figure out that user X, on team Y, is making a request for resource Z which has five form fields and this is the response to the third field, which we must have previously asked for (ex: “Enter your GitHub user id”). 

## Automating The Fulfillment
In the above example request for GitHub, the resource was configured for manual fulfillment. It means the designated fulfiller received a ticket representing the to-do item. They would manually do the work (add the user to our GitHub organization), and mark it as done.

To automate this, you can configure automated provisioning via a webtask. This is a very simple and straight-forward way to quickly call an API and get something done. In the Fulfillment tab of the resource, we can select “Webtask Auto Fulfillment”:
![Auto Fulfillment](https://images.ctfassets.net/23aumh6u8s0i/2aRfbUt5AMpunM2bSwzJF6/2ecec744f44e08a8a2b3a2cd221c3f1d/auto-fulfillment)

In the webtask code, we can grab the user’s GitHub userid from the form submitted with the request and make the API call:
![Auto Fulfill Webtask](https://images.ctfassets.net/23aumh6u8s0i/5cKuaOVtwSlrv0zBPVQFw6/9df73a1c0b08a965b7792a1b0f40a1de/auto-fulfill-wt)

Using the [webtask platform](https://webtask.io) for extensibility was a huge saver. We can let the administrators and end users customize the tool without burdening the development team. I wish every SaaS/Webapp had something like this, where, for example, you might be given a configuration choice between A or B, but maybe you want that to change depending on certain factors. The webtask platform allowed us to add this third option C to figure it out at runtime by running your own custom code. 

## Tracking
Now that a whole system is in place, it’s very easy to keep track of who has what and why. Below is a very crude interface that shows the basics, but the data is there and generating compliance reports is now trivial.

Building a lightweight certification mechanism on top of this would also be fairly straight-forward. (Certification is the process of periodically asking someone, usually a manager, if a user should still have access to X, thereby catching sensitive access that was only temporarily needed.)
![User Resource List](https://images.ctfassets.net/23aumh6u8s0i/5dU3ya3Mt3s2VKFc21dBpn/56923b5b34218f8fd182b424a7bd8720/user-resource-list)

## Engineering
From the start we wanted to design and engineer this application as if it might some-day become a product. This meant building it from the ground up with scaling, multi-tenancy, security and performance in mind. We also wanted to try out some new technologies and patterns.

The front end is a React, Single Page App. Nothing too fancy going on here beyond current modern standards and recommendations (code splitting, lazy loading, etc…)

We decided to try out GraphQL as the API interface. The data model fits pretty well for the use case. There are lots of joins happening in the data model and with GraphQL the client can get everything in one shot. 

To keep the API as light as possible, we split out the request processing and notification services into separate workers and handed them tasks via a queue.

The bot also follows this convention. We decided to not use Slack’s RTM API since it uses WebSockets, which come with different types of scaling problems. Instead, we use Slack’s Event API which functions like a webhook; we subscribe to chat messages and Slack does a POST to us with those messages. The trick here is that there could be many teams, with many channels, and if the bot is invited to very chatty channels, it will result in LOTS of POSTed messages from Slack.

_If the bot is in a channel (versus Direct Message), it only responds if called by name and it responds in a thread. This minimizes “bot-spam” in public channels._

To handle this, we have an extremely light-weight HTTP server that receives the POSTed message, replies back to Slack with a 200, and puts the data in a queue. A separate bot worker processes the messages and replies to the user. We use Redis to store the conversation sessions, so while making a request and answering questions, there could be many bot workers actually replying.

Speaking of Redis, we also have a fairly standard caching layer for things that don’t change that often (resources, groups, users, tenant settings, API tokens, etc…) we proxy those through a layer of Local Cache -> Redis -> Mongo. A solid caching strategy is especially important when using GraphQL.
![Component Architecture](https://images.ctfassets.net/23aumh6u8s0i/1UjhzXALFyO0NivWKAdsRt/20ff08968249cda32ea6cba8e8c71261/diagram)

## Aside: Securing Applications with Auth0

Are you building a [B2C](https://auth0.com/b2c-customer-identity-management), [B2B](https://auth0.com/b2b-enterprise-identity-management), or [B2E](https://auth0.com/b2e-identity-management-for-employees) tool? Auth0, can help you focus on what matters the most to you, the special features of your product. [Auth0](https://auth0.com/) can help you make your product secure with state-of-the-art features like [passwordless](https://auth0.com/passwordless), [breached password surveillance](https://auth0.com/breached-passwords), and [multifactor authentication](https://auth0.com/multifactor-authentication).

[We offer a generous **free tier**](https://auth0.com/pricing) so you can get started with modern authentication.

## Going Forward
In its current state, Phenix is a fairly solid access request platform with some light provisioning. We are planning to keep building on top of this to create a robust provisioning engine with full connector support that handles all types of CRUD operations against target systems. We are also building a reconciliation engine to sync data into the system from other sources. 

While Phenix is an internal tool for now, we are aware that it could be beneficial to others and we may decide to open it later. If you think something like this would be useful to your organization, or if you have any other thoughts or questions on this topic, please leave us a comment.


User Provisioning and Access Request with Auth0 and Webtask

a5878db74baa36ad0ae9cda759f9f2f8

Javier Centurion

We've just shipped a brand new editor for Webtask to go from 0 to code in seconds!


## Serverless Development Reimagined with the New Webtask Editor

If you are building serverless applications, then you want to get from zero to code in seconds. We've just shipped a brand new editor for Webtask which makes this desire a reality!

The Webtask Editor is a rich online environment for creating, editing and testing your Webtasks. In addition, it allows you to manage secrets, configure github two-way sync, view realtime logs, and more. It makes serverless development a breeze and you _never have to leave the browser or install anything to use it_. And with our out-of-the-box support for over 1000+ [Node modules](https://webtask.io/docs/modules?utm_source=auth0.com&utm_medium=blog&utm_campaign=webtask_editor_launch), you can get a lot of work done.

Let’s take a quick walkthrough of the experience.

## Creating a New Webtask
With the new editor, getting started can't get any easier. Just head to [webtask.io/make](https://webtask.io/make?utm_source=auth0.com&utm_medium=blog&utm_campaign=webtask_editor_launch), log in with your preferred credentials, and you'll be on your way. 

![Webtask Editor](https://images.ctfassets.net/23aumh6u8s0i/60cS0X3pZZqIkFYxNqA82I/7d4a4e2d45f2ecb51cea550e9f676292/screenshot)

From the popup dialog, you will see a few options:

- *Webtask*: this creates an empty webtask.
- *Cron*: this creates an empty scheduled webtask. 
- *Pick a template*: start coding based on selecting from a library of templates.
- *Import from GitHub*: import your code from a Github repo to a webtask.

### Webtask
Selecting "Webtask" will put you right into the editor where you can start authoring a new task.

![Create a Webtask](https://images.ctfassets.net/23aumh6u8s0i/7DNhJv22bem62OfkNLNCDY/609cf51bdc17b3056e647bcf88dbb997/new-webtask)

### Cron
Cron tasks are great for executing a task on a schedule, such as checking a Twitter feed for mentions. When you create a new cron task, you will see two panes. The left pane is the scheduler where you specify the schedule for your task and the right pane is where you put the code for your task. 

![Create a Cron with Auth0 Webtask](https://images.ctfassets.net/23aumh6u8s0i/aktaX2AvsI1rOz9eLbSZG/2794b8295c0ff1f180e24cc15d9773aa/new-cron)

For more info about cron, check [this document](https://webtask.io/docs/cron).

### Templates
Templates let you choose from a selection of starter code that you can use for building your tasks. We've included templates for integrating Webtask with common services like [Stripe](https://stripe.com), [Slack](https://slack.com), [Sendgrid](https://sendgrid.com), [Github](https://github.com), [Twilio](https://twilio.com), [Facebook](https://facebook.com), and many more. 

![Webtask Templates](https://images.ctfassets.net/23aumh6u8s0i/4ZgecL7OpNB1voK28SYpLH/2d526ba1ad9d0bc02e29ee3f04c7055a/templates)

### Importing from GitHub
If you have existing Webtasks in a repo, you can import them directly into Webtask by pointing to the repo.

## Editor Features
Now let's take a look at some of the awesome editor features.

### Runner and Logs
We've designed the new editor to streamline your development and allow you to iterate fast. To help with testing, the editor comes with an intergrated runner. In the runner you can set different HTTP methods, parameters, headers, etc. To help with debugging, we've added a realtime logs viewer that lets you view you tasks console output while it is executing.

![Webtask runner and logs](https://images.ctfassets.net/23aumh6u8s0i/7gBevZ4sa1qmi8C7NnBHLW/5dab3616501bb17f20a149ef55770ce1/runner)

### Secrets Management
If your tasks are talking to other authenticated services, you don't want to store credentials in the code. You can define new secure secrets right in the editor, which are then accessible from the code via the `context` object.

![Secrets management](https://images.ctfassets.net/23aumh6u8s0i/4tIT2Q38DvtD7hP0w7dE6z/698c9eada30c221733d8fb50910fec28/secrets)

### GitHub Integration
To take your experience up a notch, we've baked in Github integration support. This allows you to sync your webtask with a file in a Github repo. You can enable this to work bi-directionally, such that commits and pull requests to the repo result in the task automatically being deployed and any changes in the editor result in commits to the repo. You can also bind multiple tasks to different branches of the same repo, thus having dev, test, and prod versions of your tasks. It's super powerful!

![GitHub integration with Webtask](https://images.ctfassets.net/23aumh6u8s0i/70PeF2y7xmgj64x8XuU6Tr/5f1640d312490030496af901ed16ec95/github-integration)

### Task Management
Press `CMD + P` or click on the list or on the "Webtasks" icon and you'll see a list of all your tasks. From the list, you can switch to a different task, open a task in a different window, or even delete tasks. You can type into the search bar to filter the list of displayed tasks.

![Webtask Quicksearch](https://images.ctfassets.net/23aumh6u8s0i/013ieClwPQkwz7ZgygiQKT/94a6e743044be87d83bd432ec5bc75c9/quicksearch)

### Shortcuts
The new editor has tons of shortcuts for common actions within the editor as well as additional features like beautifying your code. You can see the list of shortcuts by clicking on the Shortcuts icon in the upper right corner.

![Webtask shortcuts](https://images.ctfassets.net/23aumh6u8s0i/5s8ULTLcTgcg0p459psONK/9fb487afcd17f69e08098cb9d1bdb924/shortcuts)

### CLI Support
If you like using our [CLI](https://webtask.io/cli?utm_source=auth0.com&utm_medium=blog&utm_campaign=webtask_editor_launch), we've got you covered. You can go right from the shell to the editor with the `edit` command, i.e. `wt edit mytask`.

![Webtask CLI support](https://images.ctfassets.net/23aumh6u8s0i/5Xi5ZMbIkevHxrD3eaMgMi/e8d4f572b0627611def2cd6ed385b3ab/from-cli)

## Go Try It! 
The new Webtask Editor is an amazing tool for serverless development. It will let you instantly go from idea => code => running. Not only do you get a rich browser-based authoring experience, but you get a tool to secure, test, and debug your code. Go get started playing with the Webtask editor now: [webtask.io/make](https://webtask.io/make?utm_source=auth0.com&utm_medium=blog&utm_campaign=webtask_editor_launch). Also check out our documentation at [webtask.io/docs/editor](https://webtask.io/docs/editor?utm_source=auth0.com&utm_medium=blog&utm_campaign=webtask_editor_launch).


Serverless development reimagined with the new Webtask Editor

54f3fecf3ce3bbef2d7a62b4f0496de2

Thameera Senanayaka

Learn how to create a bot that posts mentions in Zendesk to relevant Slack users using the Auth0 Webtask platform



If you’re like me, whenever you get a cool idea to create an app, the mere thought of preparing and maintaining a server always gets you down—and then there’s all the security considerations you have to think about. The advent of PaaS services like Heroku solved this problem to some extent. Now that serverless technologies have come into the mainstream, making your ideas reality is easier than ever.

Serverless platforms allow you to focus more on the code and get real work done without worrying about managing servers. Many people prefer the term function-as-a-service (FaaS) instead of serverless to serverless, because what essentially functions are the unit of application logic in this realm. Auth0's [Webtask](https://webtask.io/) is a hassle-free serverless platform you can use to deploy and run functions.

At Auth0, we tend to solve most of our problems using Webtasks. Here's an example of how we used them to create a Slack bot to tackle a pressing need we had.

## Go Beyond Basic Slack and Zendesk Integration

We’re not trying to brag, but Auth0 is known for its wonderful customer service. We use Zendesk to manage the hundreds of customer queries we get every day. Since this is an integral part of our day-to-day work, we use multiple Zendesk-to-Slack integrations to make sure we respond to every customer query in a timely manner.

For a long time, we needed the ability to mention someone else in a ticket. The only out-of-the box option was to cc that person’s email, but this had its own drawbacks. We wanted to achieve an integration that would go hand-in-hand with our primary method of communication: Slack. Zendesk has some basic Slack integration options, but it’s not programmable enough to handle mentions.

Then we thought, “Can we use a webtask to achieve this?”

## Webtasks to the rescue

Of course we can! Any time you want to automate something, you can use a webtask. We quickly implemented a Zendesk-mentions-to-Slack integration in a webtask. We didn’t need to procure any servers or worry about how much computing power or uptime we would need. All we had to do was write the code and create a trigger in Zendesk.

## Overview

Here’s an overview of the data flow in our app:

![Slack and Zendesk Integration](https://images.ctfassets.net/23aumh6u8s0i/4FPj0WOpBZklsSsdchQd0V/507cef8b51d949b8b61e23c83a55f5f5/slack-and-zendesk-integration)

Peter, a Zendesk agent, mentions his colleague Rodrigo as `<@rodrigo>`. That’s Rodrigo’s Slack username. A Zendesk trigger picks up the comment with a mention and does an HTTP POST request to our webtask. The webtask analyzes the comment and determines the exact Slack user (`@rodrigo` in this case). It then calls the Slack API to send a direct message to `@rodrigo` with details about the comment. If Peter mentioned a Slack channel name instead of a username, it would be sent to that specific Slack channel.

To set this up, we needed to do the following:

- Create a Slackbot
- Write and deploy the webtask
- Create a trigger in Zendesk

## 1. Create a Slackbot

Simply visit [this page](https://my.slack.com/services/new/bot) and enter a name for the bot. A new Slack bot will be created. After it has been created, an API token will be assigned to the bot. Make a note of this because we will need it in the next step.

## 2. Create the webtask

Now the fun begins. First, if you haven’t set up the webtask CLI, follow the three simple steps on this [webtask.io](https://webtask.io/cli) page. Once you’re done, it’s time to write the code.

Here's the code we used at Auth0. You may edit it to your liking.

```javascript
'use latest';

const request = require('request');
const _ = require('lodash@4.8.2');

const baseURL = 'https://slack.com/api/';
const usersListEndpoint = 'users.list';
const imOpenEndpoint = 'im.open';
const chatPostEndpoint = 'chat.postMessage';
let token;

/* Call the given endpoing in Slack API */
const callAPI = (endpoint, form, cb) => {
  request.post(baseURL + endpoint, {form}, (err, res, body) => {
    if (err) return cb(err);

    body = JSON.parse(body);
    if (!body.ok) return cb(body.error);

    return cb(null, body);
  });
};

/* Find Slack ID of the user with given username */
const findUser = (username, cb) => {
  callAPI(usersListEndpoint, {token}, (err, body) => {
    if (err) return cb(err);

    const user = _.find(body.members, {name: username});

    if (!user) return cb(`User ${username} not found`);
    cb(null, user.id);
  });
};

/* Open a direct msg channel with given Slack user id */
const openIM = (user, cb) => {
  callAPI(imOpenEndpoint, {token, user}, (err, body) => {
    if (err) return cb(err);
    cb(null, body.channel.id);
  });
};

/* Post message to specified Slack channel */
const postMsg = (channel, data, cb) => {
  const obj = {
    title: `#${data.id} | ${data.title}`,
    title_link: 'https://auth0.zendesk.com/agent/tickets/' + data.id,
    fields: [
      {title: 'Mentioned by', value: data.author},
      {title: 'Comment', value: data.comment},
      {title: 'Tags', value: data.tags}
    ]
  };
  callAPI(chatPostEndpoint, {
    token,
    channel,
    as_user: false,
    username: 'Zendesk Mentions Bot',
    icon_url: 'http://i.imgur.com/IhN4IzR.png?1',
    text: 'You were mentioned in this ticket:',
    attachments: JSON.stringify([obj])
  }, (err, body) => {
    if (err) { console.log(err); return cb(err); }
    cb(null);
  });
};

/* Extract mentioned user's name from comment */
const extractName = (comment) => {
  const start = comment.indexOf('<@') + 2;
  const end = comment.substr(start).indexOf('>');
  return comment.substr(start, end);
};

module.exports = (context, cb) => {

  // Slack bot token
  token = context.data.BOT_TOKEN;

  const name = extractName(context.data.comment).toLowerCase();

  findUser(name, (err, id) => {
    if (err) {
      // If no such user, assume it's a channel
      return postMsg(name, context.data, cb);
    }

    return openIM(id, (err, channelId) => {
      if (err) { console.log(err); return cb(); }
      else postMsg(channelId, context.data, cb);
    });
  });

};
```

That’s less than 100 lines of code!

The entry point to the code is the line starting with `module.exports = (context, cb) => {`. When the webtask is triggered, this function will be executed, which will in turn call the rest of the functions when necessary.

For security reasons, we add the bot’s token as a configuration (as described below) instead of in the code. Then we find the mentioned name from the comment text. We check Slack to see if such a user exists. If not, we assume it’s a channel name and post it into the channel with that name. If a user is found, we open an IM channel with that user and post the message.

Save this code in a file named `slackmention.js` and enter the following command to deploy it as a webtask:

```
wt create --secret BOT_TOKEN=<Slack bot token from step 1 goes here> slackmention.js
```

After the webtask is deployed, the CLI will present you with its unique URL. We will use this in the next step.

## 3. Create a trigger in Zendesk

The last step is to tell Zendesk to call our webtask when it sees a comment that might have a mention in it. You need to be an admin in Zendesk to do this. If you are not, reach out to your friendly Zendesk admin (and don’t forget to give them a cookie!).

In Zendesk, go to **Settings > Extensions** and create a new HTTP target with the webtask’s URL as the URL (obtained in Step 2), POST as the method, and JSON as the content type.


Now go to **Settings > Triggers** and create a new trigger with _‘Ticket: Comment text...’_ as the condition, “Contains the following string” as the op, and `<@` as the string. The performed action should be _‘Notifications: Notify target’_ set to the HTTP target created above. Set the JSON body as follows:

```json

{ "id": "{{ticket.id}}", "title": "{{ticket.title}}", "comment": "{{ticket.latest_comment}}", "author": "{{ticket.latest_comment.author.name}}", "tags": "{{ticket.tags}}" }

```

## Test it!

Now we are all done. To test our new setup, add the following comment in a new (or existing) Zendesk ticket. You can add it to a public comment or an internal comment.


```
Hello <@thameera>!
```

Replace `thameera` with your Slack username, of course. If you performed all the steps in order, you will get a Slack notification like this:

![Slack mention in the Zendesk ticket](https://images.ctfassets.net/23aumh6u8s0i/6vYCYmGihKFIEtHrecV9Kd/04d132295f04d63293749edb6f7b0f0a/zendesk-bot-with-slack-mention)

That’s it! You can customize the trigger and the webtask to suit your company’s needs and deploy your own Zendesk-to-Slack-mentions implementation in a few minutes. For example, you can modify it to send an email or send a DM via HipChat if that’s your chat application of choice.

## Conclusion

The next time you need to create a bot, automate something, or write a program, remember that you can use a webtask to say no to [yak shaving](http://www.hanselman.com/blog/YakShavingDefinedIllGetThatDoneAsSoonAsIShaveThisYak.aspx) and focus on your code.

You can start experimenting with webtasks by creating a free Auth0 account below or heading directly to [https://webtask.io](https://webtask.io). Enjoy!


Build a Serverless Slack Bot with Webtask.io

99c4080f412ccf46b9b564db7f482907?s=200 avatar

99c4080f412ccf46b9b564db7f482907?s=200

I'm currently a Senior Developer Advocate at MongoDB. I'm also a Google Developer Expert for Web Technologies and spend most my time giving talks at conferences and meetups, mentoring developers and running workshops, and creating online content to help technology professionals.

Ado Kukic

Learn how to build a serverless app with Lambda, the function-as-a-service platform from Amazon. Find out how AWS Lambda stacks up against Webtask.

Building Serverless Apps with AWS Lambda

Learn how to fix your Twitter share count with a simple HTTP proxy without a server using Webtasks



Recently Twitter decided to [shutdown](https://blog.twitter.com/2015/hard-decisions-for-a-sustainable-platform) one of its unofficial API endpoints: the URL share count. In this post we will show you how to get that functionality back with a simple [Webtask](https://webtask.io) acting as a proxy to a different counts provider.

-----

## The problem
Twitter used to provide a *non-public* API endpoint for URL share counts:

```
$ curl http://cdn.api.twitter.com/1/urls/count.json?url=http://my.url.com
{"count":27438,"url":"http:\/\/my.url.com\/"}
```

![Twitter share count](https://images.ctfassets.net/23aumh6u8s0i/4m43U8hB07Ec0PsCc2RrGu/2aea8f8a6794a65f6ff7200ee93c9a85/twittercount)

Although this endpoint was not public (and therefore Twitter never committed to supporting it), it stayed available for a long time and people started using it. Unfortunately this [changed recently](https://blog.twitter.com/2015/hard-decisions-for-a-sustainable-platform). However the need for a Twitter URL share count remained. At Auth0 we use URL share counts in our [blog](https://blog.auth0.com), so we had to find a way to fix this.

> It should be noted that as the endpoint was not public Twitter really can't be blamed for removing it.

## The alternative
So we set out to find an alternative service providing link counts on Twitter. We found [OpenShareCount](http://opensharecount.com/). The service basically works by performing periodic searches using the official Twitter search API, then counting the results and storing them for quick retrieval. If you are familiar with the Twitter API, then this should trigger an alarm: Twitter searches only go back a few days, so count results are not absolute. OpenShareCount resolves this by running the search periodically and adding up newer results. Good enough.

After signing up and setting up your domain for counts, a simple call to OpenShareCount's API will do the thing:

```
$ curl http://opensharecount.com/count.json?url=http://my.url.com
{"count":27438,"url":"http:\/\/my.url.com\/"}
```

> It should be noted that OpenShareCount does not support JSONP (using the callback parameter) as the old Twitter API did, so further changes to your site might be needed.

Looking good. However we still have one problem to solve: cross site requests.

## Another problem: the same origin policy
Our blog is hosted at [https://blog.auth0.com](https://blog.auth0.com) and OpenShareCount provides the API endpoint at `http://opensharecount.com/count.json?url=http://my.url.com`. There are two things we need to take into account:

1. The `Access-Control-Allow-Origin` header.
2. The use of the same communications protocol (HTTP or HTTPS).

By running a simple cURL test to the URL we see the `Access-Control-Allow-Origin` header is correctly set:

```
curl -v http://opensharecount.com/count.json\?url\=http://my.url.com
*   Trying 104.27.164.180...
* Connected to opensharecount.com (104.27.164.180) port 80 (#0)
> GET /count.json?url=http://my.url.com HTTP/1.1
> Host: opensharecount.com
> User-Agent: curl/7.45.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 10 Dec 2015 17:07:23 GMT
< Content-Type: text/html; charset=ISO-8859-1
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=d953733a4896a8010a92b07f02928451f1449767243; expires=Fri, 09-Dec-16 17:07:23 GMT; path=/; domain=.opensharecount.com; HttpOnly
< Vary: Accept-Encoding
< Access-Control-Allow-Origin: *
< CF-Cache-Status: MISS
< Expires: Thu, 10 Dec 2015 17:37:23 GMT
< Cache-Control: public, max-age=1800
< Server: cloudflare-nginx
< CF-RAY: 252a8bb960980320-MIA
<
* Connection #0 to host opensharecount.com left intact
{"url":"http://my.url.com","error":"Domain my.url.com not authorised, register for free at http://opensharecount.com first","count":0}
```

So the `Access-Control-Allow-Origin` header is not a problem. However the difference between HTTPS and HTTP *is*. Browsers forbid AJAX requests to non-TLS resources from a TLS-secured page.

### A Webtasks Proxy
The obvious solution to the problem above is a *proxy*. This proxy will simply provide a HTTPS frontend for the HTTP OpenShareCount API. This is a simple matter, but forces us to think about hosting, load-balancing and other stuff related to setting up a new service. As we face these problems daily, at Auth0 we developed [webtasks](https://webtask.io), which fit this problem domain perfectly.

Here's our simple HTTP to HTTPS proxy:

```
var url = require('url');
var request = require('request');

module.exports = function (ctx, cb) {
  var whitelist = ['metrics.it.auth0.com', 'opensharecount.com'];

  var targetUrl = ctx.data.url;
  var target = url.parse(targetUrl).hostname;
  var ok = whitelist.some(function (host) {
    return target === host;
  });

  if (!ok) {
    return cb(new Error('no way'));
  }

  request.get({url: targetUrl}, function(err, resp, body) {
     if (err) return cb(err);
     cb(null, JSON.parse(body));
  });
};
```

And this is our endpoint with parameters: `https://webtask.it.auth0.com/api/run/auth0/proxy?webtask_no_cache=1&url=http://opensharecount.com/count.json?url=LINK_COUNT_URL`

The proxy has a simple embedded whitelist to prevent misuse by third-parties. After running the whitelist filter, it performs an HTTP request and sends back the result to the original caller.

> Please note that browser restrictions with regards to access to unprotected resources from a TLS secured page are in place for a reason. Study carefully if the unprotected resource can be handled this way before doing something like this.

## Get Your Twitter Share Counts Back: Create Your Own Webtask!
If you are interested in learning more about webtasks or creating your own, head over to [https://webtask.io](https://webtask.io) and get started. With the webtasks command line interface, creating your first script is a matter of running a few commands:

<include src="TweetQuote" quoteText="With the webtasks command line interface, creating your first script is a matter of running a few commands."/>

```
npm install wt-cli -g
wt init your@email.com
echo "module.exports = function (cb) {cb(null, 'Hello');}" > hello.js
wt create hello.js
```

You can then run the webtask:

```
curl https://webtask.it.auth0.com/api/run/wt-sebastian_peyrott-auth0_com-0/hello?webtask_no_cache=1
```

Replace your webtask URL by the one returned by `wt create`.

## Conclusion
The decision to remove the link counts API by Twitter was unfortunate but perfectly understandable. It was never meant for public use. Fortunately OpenShareCount and Webtasks make a perfect fit for solving this issue as soon as possible and in a convenient manner. If you decide to use or extend our simple proxy sample, let us know in the comments. Good luck!


"web server"