Alexa Account Linking Configuration

To get started with Alexa Account Linking configuration, we need to configure the account linking parameters on the Alexa Skill Interface. This is done on the configuration page in the Alexa Developer Console.

We can configure our Skill to enforce account linking, i.e., the user has to link his account as a precondition for using the Skill. If this setting is active and the account is not linked, the Skill will not be available. Alternatively, the enforcement of account linking can be removed, allowing the user to activate and use the Skill without a linked account. Enforcement may make sense if the Skill is only usable with a linked account.

Configuration page in Alexa Developer Console to set up Alexa Account Linking

In the section called Security Provider Setting on the Account Linking Tab in the Alexa Developer Console, we need to provide the OAuth Server configuration. The values for these parameters are provided by the OAuth provider (e.g., Spotify) and from the registration of the Skill with the OAuth provider:

  • Authorization URL: URL for end-user login provided by the OAuth     provider (e.g. Spotify).
  • Grant Type: Different flavors of OAuth, choose Auth Code Grant, unless specified otherwise by the OAuth provider.
  • Token URLs: URL of the service providing Access Tokens provided by     the OAuth provider (e.g., Spotify).
  • ClientID: ID of the Alexa Skill, provided by the OAuth provider (e.g. Spotify) after registering the Skill as an App on their  website.
  • ClientSecret: Password of the Alexa Skill, provided by the OAuth     provider (e.g. Spotify) after registering the Skill as an App on their website.
  • Authentication Scheme: for authentication of the client on the token endpoint. Typically this is Basic Auth, but check with the OAuth provider (e.g. Spotify).
  • Scopes: List of specific access rights we need from the OAuth     provider. We need access rights to the playlists of the user.

Some non-standard information is asked as well:

  • Domains: This is a whitelist to prevent cross-site attacks. All domains, which the login page (Authorization URL) can load data from, must be listed here. E.g. if the login page displays an image from a CDN (Content Delivery Network), the domain of the CDN needs to be listed here.
  • Access Token Expiration Time: This is a fallback solution. Usually the OAuth server provides the token expiration time. The expiration time here is used as a fallback, if the OAuth server does not provide the token expiration time.
  • Redirect URL: Alexa provides the redirect endpoint, which can receive an OAuth authorization code and request an OAuth access token. For redundancy, there are several redirect endpoints with different domains, which all behave the same way. All or one of them need to be provided to the OAuth Server.

Check out the other posts in this series on Alexa Account Linking:

In my new book “Making Money with Alexa Skills – A Developer’s Guide” I describe not only how to develop, but also how to monetize Alexa Skills. Account linking is one of the possibilities for personalizing a Skill and make it unique – more practical approaches for personalizing Skills are described in the book. https://api-university.com/books/alexa

In the OAuth 2.0 book you can find a simple and understandable explanation of all the standard OAuth Flows (such as those supported by Alexa). What makes this book unique is that the complicated OAuth interactions are visualized as easy-to-understand Sequence Diagrams. https://api-university.com/books/oauth-2-0-book/

Part 2 of Alexa Account Linking Configuration

Also published on Medium.

Tagged on:         

Matthias Biehl

As API strategist, Matthias helps clients discover their opportunities for innovation with APIs & ecosystems and turn them into actionable digital strategies. Based on his experience in leading large-scale API initiatives in both business and technology roles, he shares best practices and provides both strategic and practical guidance. He has stayed a techie at heart and at some point, got a Ph.D. Matthias publishes a blog at api-university.com, is the author of several books on APIs, and regularly speaks at technology conferences.