This tutorial will show you how you can add support for the French (Canada) model for your existing skills. It will also show you how you can use ASK to enable Alexa to respond based on locales.[Read More]
Today, we announced that Amazon Alexa and Alexa-enabled devices are coming to Spain later this year. Starting today, you can use the Alexa Skills Kit (ASK) to build skills for customers in Spain using the new Spanish language model.[Read More]
Today, we announced that Amazon Alexa and Alexa-enabled devices are coming to Italy later this year. Starting today, you can use the Alexa Skills Kit (ASK) to build skills for customers in Italy using the new Italian language model.[Read More]
Today, we announced that Amazon Alexa and Alexa-enabled devices are coming to France later this year. You can start using the Alexa Skills Kit (ASK) to build skills for customers in France using the new French language model.[Read More]
This new technical tutorial by Sr Solutions Architect for Amazon Alexa, Sebastien Stormacq will show you how to use Amazon API Gateway and configure it to act as a HTTP Proxy, sitting between Alexa and your OAuth server.
Have you ever developed an Alexa skill that uses account linking? Do you remember the first time you tried to click on the “Link Account” button and feared for the result? I bet you first saw the dreadful error message: “Unable to Link your skill”. Sometimes trying to figure out what an error is, is like searching for a needle in a haystack. You have no clue.
Most of the errors that I have seen when working with developers, fall in two categories:
When you have access to the OAuth server logs, debugging the error message you see in the Alexa App is relatively easy. You just enable full HTTP trace on the server side and search for the error or the misconfiguration on the server. Full HTTP trace includes the full HTTP headers, query string and body passed by the Alexa service to your server.
With a bit of experience, catching an OAuth error in HTTP stack trace takes only a few minutes.
The problem is that most developers we are working with, have no access to the OAuth servers or the server logs. Either they are using a third party OAuth server (Login With Amazon, Login With Facebook, Login with Google and the likes), or they are working in a large enterprises where another team is operating the OAuth server. Meeting that team and asking them to change logging level or to request access to the logs can take weeks, or may not be possible at all.
This article explains how to setup an HTTP proxy between Alexa Skill Service and your OAuth server to capture all HTTP traffic and log it. By analyzing the logs, you can inspect the HTTP URLs, query strings, headers and full bodies exchanged. Setting such a proxy requires infrastructure to host the proxy: a networked server, with a runtime to deploy your code etc … this is unnecessary heavy lifting where Amazon Web Services can help.
We will use Amazon API Gateway instead and will configure it to act as an HTTP Proxy, sitting between Amazon’s Alexa Skill Service and your OAuth server.
Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. With a few clicks in the AWS Management Console, you can create an API that acts as a “front door” for applications to access data, business logic, or functionality from your back-end services.
API Gateway HTTP Proxy Integration mode is a new feature of API Gateway that was launched on Sept. 20th 2016. You can read the post by AWS Director of Evangelism, Jeff Bar’s, if you want to learn more about this.
The diagram below shows where API Gateway, with HTTP Proxy Integration, fits in the OAuth Architecture.
Discover how to use account linking with Login with Amazon to seamlessly integrate your Alexa skills with third-party application. Get step-by-step instructions from Sebastien Stormacq, Sr. Solutions Architect at Amazon.
Some skills require the ability to connect the identity of an Alexa end user with a user in another system, such as Twitter, Facebook, Amazon, and many others. For example, suppose you own a web-based service “Car-Fu” that lets users order taxis. It would be very convenient for people to access Car-Fu by voice (“Alexa, ask Car-Fu to order a taxi”).
To accomplish that, you’d use a process called account linking, which provides a secure way for Alexa skills to connect with third-party systems requiring authentication.
Skills that use the Smart Home Skill API must use account linking (with the authorization code grant flow) to connect the Alexa user with their device cloud account. Custom skills can use account linking if desired. However, if your custom skill merely needs to keep track of a user to save attributes between sessions, you do not need to use account linking.
There are many ways you can use account linking to enhance your Alexa skills. For example:
Account linking leverages OAuth 2.0; an open protocol that provides a simple, standards-based method for web, mobile and desktop applications to request user authorization from remote servers.
As a skill developer, you could set up and configure your own OAuth server and identity management system. At some large companies, an OAuth server is probably already available and Identity Management procedures already in place. However, at smaller companies, this would require you to build, operate, and maintain your own complex system to manage user identities, passwords, and profiles in a secure and scalable way.
Many organizations rely instead on well-known identity providers, available on the internet. These are sites where nearly everyone has an account, such as Facebook, Google, Twitter, and Amazon. The service that acts as a public-facing identity provider for Amazon is Login with Amazon.
When using OAuth, you delegate user authentication to a third-party Identity Provider (IDP). As illustrated below, the user is redirected to the IDP web site. User authentication happens according to the IDP’s policies (username and password, one-time password, biometric, etc.), and upon successful authentication, the IDP generates an implicit grant (aka bearer token) or an authorization code grant.
The bearer token is the token you'll use for accessing information and services. On the other hand, an authorization code can only be used to request a bearer token. This usually happens on the backend, between your application server and the IDP service. While an implicit grant is often faster and simpler for developers to request, an authorization code grant is generally considered more secure and some IDPs may require it for sensitive information or services. Also, a code grant allows for automatic refreshing of the bearer token after a given expiry, which will be set according to the IDP’s policy. When using an implicit grant, the user has to manually re-authenticate themselves when attempting to use the service, which, depending on the lifespan of the bearer token, can cause friction for account linking in applications.
After authentication is complete and a valid token is received, your application is responsible for managing authorization based on the customer's profile.
Figure 1 : OAuth data flow
Follow these steps to configure your Alexa skills with account linking and Login with Amazon.[Read More]