アクセスいただきありがとうございます。こちらのページは現在英語のみのご用意となっております。順次日本語化を進めてまいりますので、ご理解のほどよろしくお願いいたします。

How Account Linking Works

Alexa skills use OAuth 2.0 for account linking. This topic describes OAuth 2.0 terms and how your skill fits in.

OAuth roles and Alexa skills

OAuth 2.0 specifies four roles: resource owner, resource server, client, and authorization server. The following table defines the roles and shows how the roles work in the context of the Alexa Skills Kit.

Role OAuth Definition Role within a Custom Skill

Resource owner

The individual who can grant permission to access a protected resource in the resource server.

The Alexa user who wants to connect your skill with their user account in your system and access a protected resource in that system.

For a custom skill that lets users order rides ("Ride Hailer"), this is the user who wants to enable the Ride Hailer skill and link it to their Ride Hailer account so that they can request rides.

Resource server

The server hosting the resources the user wants to access.

In the Ride Hailer example, the resource server might be a database containing profiles for Ride Hailer users. The protected resource is the user's Ride Hailer account profile with their payment information, stored in this database.

Client

The application making the requests to the resource server on behalf of the resource owner, with the resource owner's authorization.

The skill. The skill uses the access token to request information from the resource server.

Note that although the skill is the OAuth client, Alexa performs some operations on behalf of the skill. For example, Alexa makes the requests to the authorization server to get the access token. The skill is still considered the client since it is the only component that ever accesses the protected resources in the resource server.

In the Ride Hailer example, the Ride Hailer skill communicates with the resource server to retrieve the user’s Ride Hailer account profile with their payment information, so that the skill can order the user a ride.

Authorization server

The server that authenticates the identity of the resource owner and issues access tokens. This can be the same as the resource server, but it does not have to be.

In the Ride Hailer example, the authorization server authenticates the user and provides an access token identifying the user as a valid Ride Hailer user. The token can then be used to retrieve the user's Ride Hailer account information from the resource server.

Role OAuth Definition Role within a Smart Home Skill

Resource owner

The individual who can grant permission to access a protected resource in the resource server.

The Alexa user who wants to connect your smart home skill with their user account in the device cloud.

For a skill that can control lighting ("My Lights"), this is the user who wants to enable your skill and link it to their My Lights account so that they can control their My Lights devices with Alexa.

Resource server

The server hosting the resources the user wants to access.

In the My Lights example, this is the cloud-based My Lights service that can control light switches in a user's home. The protected resource is the user's My Lights account, with information about the user's smart devices that the service controls.

Client

The application making the requests to the resource server on behalf of the resource owner, with the resource owner's authorization.

The skill. The skill uses the access token to request information from the resource server.

Note that although the skill is the OAuth client, Alexa performs some operations on behalf of the skill. For example, Alexa makes the requests to the authorization server to get the access token. The skill is still considered the client since it is the only component that ever accesses the protected resources in the resource server.

In the My Lights example, the My Lights skill communicates with the resource server to retrieve information about the user's lights that it can then use to turn a light on or off.

Authorization server

The server that authenticates the identity of the resource owner and issues access tokens. This can be the same as the resource server, but it does not have to be.

In the My Lights example, this server authenticates the user and provides an access token identifying the user as a valid My Lights user.

Who owns the resource server and authorization server?

The resource server and authorization server do not need to be owned by the same person or company. Some of the common scenarios include:

Scenario What this means Example

You own both the resource server and the authorization server.

You built your own the authorization server for your service.

You built the Ride Hailer service. As part of this service, you built both the resource server that stores Ride Hailer profiles, and the authorization server that issues tokens granting access to the user profiles in the Ride Hailer system.

You own the resource server, but not the authorization server.

You use a third-party authorization server such as Login with Amazon. The authorization server provides you with data you can map to your users in your resource server.

You own the Ride Hailer service, but you did not build an authorization server. Your resource server contains profile data for your users. You use Login with Amazon to authenticate users, and then use the Amazon profile:user_id to access a user's profile in your Ride Hailer database.

You own neither the resource server nor the authorization server.

You are connecting to a third-party API that requires user authentication.

You don't own Ride Hailer, but Ride Hailer exposes a public API that supports OAuth 2.0. You build an unofficial Ride Hailer skill that connects to the public API, authenticates the user, and makes an API call to order a car ride.

Grant types and skill models

In OAuth 2.0, a grant refers to how an application acquires an access token that allows it to access a resource. The type of authorization grant your skill can use for account linking depends on your skill model, as shown in the following table.

Skill model Authorizing users

Custom model

Can use either authorization code grant or implicit grant to authorize the user and obtain an access token.

Smart home model
Video model
Meetings model

Must use authorization code grant to authorize the user and obtain an access token.

Music model

Must use authorization code grant to authorize the user and obtain an access token.

Baby activity

Must use mutual authentication and reciprocal access tokens.

Information you need for account linking

For any scenario in which you do not own or did not build all of the components, consult the third-party documentation for the third-party service to determine:

OAuth Resources:

Other resources: