Amazon Web Services Blog: Identity and Access Management
Amazon Web Services, Products, Tools, and Developer Information...
, Principal Product Manager on the AWS Identity and Access
Management (IAM) team sent along a guest post to introduce a powerful new federation feature.
In a previous blog post we discussed how
by allowing developers to grant temporary security credentials
to users managed outside of AWS. Today we’re expanding this capability with
support for web identity federation.  Web identity federation simplifies the
development of cloud-backed applications that use public identity providers
such as , , or the newly launched
service for authentication.
For those of you not yet familiar with Login with Amazon, it's a new service you can
use to securely connect your websites and apps with millions
customers.
If you’re interested in learning more about Login with Amazon, please visit their
Web identity federation enables
your users to sign in to your app using , Facebook, or Google
identity and authorize them to seamlessly access AWS
resources that are managed under your AWS account. If you are building a
mobile or a client-based application, you can now integrate these three popular identity providers and
authorize users without any server-side code and without distributing long-term
credentials with the app. To support this scenario, this release introduces a
new AWS Security Token Service (STS) API, AssumeRoleWithWebIdentity. This API lets you request
temporary security credentials for your customers who have been authenticated
, Facebook, or Google. Your app can then use the temporary
security credentials to access AWS resources such as Amazon Simple Storage
Service (S3) objects, DynamoDB tables, or Amazon Simple Queue Service queues.
Let's walk through an example use case.
Imagine you’re developing a mobile app that uses the new Login with Amazon
service for authentication, and part of the app’s functionality allows end
users to upload an image file as their personal avatar. Behind the scenes, you
want to store those images as objects in one of your S3 buckets. To enable this,
you need to configure a role that is used to delegate access to users of your app. Roles are configured in two parts:
A trust policy that specifies a trusted entity (principal)—that is, who can assume the role. In this case, the trusted entity is any
An access policy with permissions that specify what the user can do.
Setting up a trust policy for
Login with AmazonFirst we’ll create the trust policy. For this example, let’s assume you’ve
registered your app with Login with Amazon and you’ve been assigned an
application identifier (app_id) of amzn1.app.123456SAMPLE. This application ID uniquely identifies your
app with Login with Amazon. (If you register the app with Facebook or Google, you'll
get a different app ID from each of these providers.) To delegate access
users, the trust policy for your role needs to include the new federated
principal type
the app_id
value. The following trust policy allows
user who has
authenticated using your app to call the sts:AssumeRoleWithWebIdentity
API and assume the role.
&Version&:&&,
&Statement&:[{
&Principal&:{&Federated&:&&},
&Effect&:&Allow&,
&Action&:&sts:AssumeRoleWithWebIdentity&,
&Condition&: {&StringEquals&:{
&:app_id&:&amzn1.app.123456SAMPLE&}
Notice that we have introduced a new type of key that can be used in policy conditions—we
now have support for identity-provider–specific keys , Facebook,
and Google. In this case, the :app_id key ensures that
the request is coming from your app by doing a string comparison against your app's
registered ID. (To read more about the new policy keys that support web
identity federation, see
in the AWS STS guide.)
Next, let’s create an access policy for the role.
Sample Policy Allowing S3 Access
The following access policy grants end users of your app limited access to
an S3 bucket named myBucket in your AWS account. Specifically, it grants
every user read-only access (Get*) to a shared folder whose prefix matches
the app_id
value, and it grants read, write, and delete access (GetObject, PutObject,
and DeleteObject)
to a folder whose prefix matches the user ID provided by Amazon. Notice that
the new identity provider keys described in the previous section, such as ${:app_id},
can also be used as . In this case, we’re also using ${:user_id},
which contains the user’s
ID. (Remember, when using a
variable you must always set the Version element to .)
&Version&:&&,
&Statement&:[{
&Effect&:&Allow&,
&Action&:[&s3:Get*&],
&Resource&:[&arn:aws:s3:::myBucket&],
&Condition&:
{&StringEquals&:
{&s3:prefix&:[&${:app_id}&,&${:app_id}/&]}
&Effect&:&Allow&,
&Action&:[&s3:GetObject&, &s3:PutObject&, &s3:DeleteObject&],
&Resource&:[
&arn:aws:s3:::myBucket/${:app_id}/${:user_id}&,
&arn:aws:s3:::myBucket/${:app_id}/${:user_id}/*&
Putting it All TogetherNow that the role has been created, let’s take a look at how the role will
be used to provide federated access to your end users. The following diagram
illustrates the steps that occur to authenticate
authorize the user to access objects in an S3 bucket.
First, the user needs to be authenticated. Using the Login with Amazon SDK, the app authenticates the user and receives a token from Amazon.
Next, the user needs to be authorized to access resources in your AWS account. The app makes an unsigned AssumeRoleWithWebIdentity request to STS, passing the token from the previous step. STS verifies the authe if the token is valid, STS returns a set of temporary security credentials to the app. By default, the credentials can be used for one hour.
Finally, the app uses the temporary security credentials to make signed requests for resources in your S3 bucket. Because the role's access policy used variables that reference the app ID and the user ID, the temporary security credentials are scoped to that end user and will prevent him or her from accessing objects owned by other users.
This is just one example of how web identity federation can be used. A
similar flow can also be enabled for Facebook or Google identities by integrating
their SDKs with your app and simply creating an additional role. For more information
about web identity federation and how to create roles that support other identity
providers, please see
in the AWS STS guide.
-- Jeff Wierer
now supports role-based permissions and management via AWS . 
Let's review the key terms before diving in to the details:
AWS Marketplace makes it easy to find, buy, and 1-click deploy software to the cloud, featuring hundreds of popular commercial and open-source software products for developers, IT admins, and business users.
AWS Identity and Access Management (IAM) offers greater security, flexibility, and control when using AWS. For larger businesses, IAM enables identity federation between your corporate directory and AWS services.
What is Subscribing?
AWS Marketplace lets you browse through more than 25 categories of software, including the most pop operating systems, application infrastructure, and business applications. When you find software that you want to use, you &subscribe& to the software. AWS Marketplace then creates EC2 instances to run the software.  
EC2 instances can be launched either immediately, as part of the subscription process, or later (e.g. during the development cycle). The software is delivered as an AMI, so when you’re ready to create an EC2 image with the AMI, you can do so through the Marketplace UI, or alternatively through the same EC2 API or command line statements that you use for any other AMI.  Once you’ve subscribed to software, the Marketplace AMI looks to you just like any of your other AMIs.
As the AWS account owner, you now have fine-grained control over usage and software costs. Roles and permissions are created and managed through IAM, making it easy to get started, and easy to add controls for AWS Marketplace to new or existing IAM groups. You can now use Marketplace permissions to control access to Marketplace and to the EC2 instances that it launches, based on a user's role in the business. For example you can set up your account so that:
Managers and employees of the Finance Department can manage subscriptions but can't run or terminate EC2 instances.
Developers and IT personnel can inspect, run, and terminate EC2 instances, but cannot subscribe to applications.
Marketplace actions are now controlled by IAM permissions.
With the new IAM integration, we are providing three pre-made templates (these can be fully customized or changed, just like any other IAM template):
The permissons in the View Subscribed Software template are generally designed for administrators, staff concerned with technical standards, or anyone else interested in understanding usage and adoption of software, but who don't need to actually create or manage particular instances of software. 
The Manage Subscriptions permissions let a user subscribe to software, but not start or manage particular EC2 that run the software. This is useful for technical standards, procurement, or admin staff who want to enable or approve software for use inside an organization, but who do not need to create particular instances of the software. 
Finally, the permissions in the Full Control template combines the permissions from the previous templates while adding in administrative EC2 permission, thereby enabling a user to subscribe to new software, as well as create and manage EC2 images running that software.
Our goal with these templates is to make it very easy for a company to get started with AWS Marketplace without the worries of losing control over software costs or usage. For organizations that have a strong procurement and standards function, the Manage Subscriptions and Manage EC2 roles make it easy to support workflows and use cases where approving software for use is a separate responsibility from actual implementation.  However, for more decentralized organizations, the Full Control permission duplicates the existing Marketplace experience, letting a single user find, buy, and deploy software in a matter of minutes.  Meanwhile, the View Subscribed Software role can be used to oversee and audit usage.
Here's a walkthrough so that you can see how these features work together.
First, some new IAM users are created:
One of the users tries to launch an application in the AWS Marketplace. They are informed (via the message in the yellow box) that they do not have permission to do so:
They are then given the appropriate permissions via an IAM policy:
The users can log into AWS Marketplace using the IAM user name that they’ve been given. Then can then make changes to subscriptions in AWS Marketplace:
PS - We've been adding new application check it out if you have yet to visit.
In August, we announced that AWS Identity and Access Management (IAM) added support for Identity Federation. This enabled customers to use their existing identities (e.g. users) to securely access AWS APIs and resources using IAM's fine-grained access controls, without the need to create an IAM user for each identity.Today we are announcing that we have extended IAM’s Identity Federation functionality to also enable federated users to access the AWS Management Console. This allows you to enable your employees to sign in once to your corporate directory, and then use the AWS Management Console without having to sign in to AWS, providing single sign-on access to AWS.
In my , I discussed how you could setup an identity broker, which calls our Security Token Service (STS), requesting temporary security credentials to provide your users access to AWS. You explicitly specify the permissions that these temporary credentials give your users, as well as control the amount of time (1 to 36 hours) these credentials are valid for. Well, these same temporary security credentials can now also be used to access the AWS Management Console.
Here's the basic flow:
User signs in to the enterprise network with their enterprise credentials.
User browses to an internal site and clicks on Sign in to AWS Management Console.Page calls identity broker. Identity broker validates access rights and provides temporary security credentials which includes the user's permissions to access AWS. The page includes these temporary security credentials as part of the sign-in request to AWS.
User is logged in to the AWS Management Console with the appropriate IAM policy.
If you have already built an identity broker, perhaps using our , to enable Identity Federation to AWS service APIs for users in your enterprise directory, you’re already most of the way there. All you need to do is implement an internal web page with redirect links to the AWS Management Console, and include the temporary security credentials as part of the sign in request. Below is some simple Ruby code sample that shows how to do just that (just replace the highlighed items with your own identifiers and URLs):
require 'rubygems'
require 'json'
require 'open-uri'
require 'cgi'
require 'aws-sdk'
# The temporary credentials will normally come from your identity
# broker, but for simplicity we create them in place
sts = AWS::STS.new(:access_key_id =& &*** Your AWS Access Key ID ***&,
  :secret_access_key =& &*** Your AWS Secret Access Key ***&)
# A sample policy for accessing SNS in the console.
policy = AWS::STS::Policy.new
policy.allow(:actions =& &sns:*&,:resources =& :any)
session = sts.new_federated_session(
  &UserName&,
  :policy =& policy,
  :duration =& 3600)
# The issuer parameter specifies your internal sign-in
# page, for example https://mysignin./.
# The console parameter specifies the URL to the destination tab of the
# AWS Management Console. This example goes to the sns console.
# The signin parameter is the URL to send the request to.
issuer_url = &https://mysignin./&
console_url = &https://console./sns&
signin_url = &https://signin./federation&
# Create the signin token using temporary credentials,
# including the Access Key ID, Secret Access Key, and security token.
session_json = {
  :sessionId =& session.credentials[:access_key_id],
  :sessionKey =& session.credentials[:secret_access_key],
  :sessionToken =& session.credentials[:session_token]
get_signin_token_url = signin_url + &?Action=getSigninToken&SessionType=json&Session=& + CGI.escape(session_json)
returned_content = URI.parse(get_signin_token_url).read
signin_token = JSON.parse(returned_content)['SigninToken']
signin_token_param = &&SigninToken=& + CGI.escape(signin_token)
# The issuer parameter is optional, but recommended. Use it to direct users
# to your sign-in page when their session expires.
issuer_param = &&Issuer=& + CGI.escape(issuer_url)
destination_param = &&Destination=& + CGI.escape(console_url)
login_url = signin_url + &?Action=login& + signin_token_param + issuer_param + destination_param
You can control the user name displayed in the upper right corner of the AWS Management Console when your user logs in. You can also optionally provide an &Issuer& URL when signing your users in. This URL will then be displayed to the user when their credentials expire, so they can re-authenticate with your identity system before continuing to use the AWS Console.
The following services support Identity Federation to the AWS Management Console today: , , , , , , , , , , , , and . We'll of course be adding support for additional service consoles over time (the busy
team is already working on it!).
You can now create custom IAM () policy documents from the . You can use a custom policy document to gain access to a number of advanced IAM features such as limiting access by user agent, time, or IP address, requiring a secure transport, or even enabling cross-account access to selected AWS resources.
Here's a tour! The first step is to click on the Attach User Policy button (you can also do this for IAM groups):
There's a new Policy Generator option:
The Policy Generator allows you to create policy documents for any AWS service that is supported by IAM:
After selecting a service you can choose to allow or deny any number of actions in the policy document that you create:
You can also attach any number of conditions to each of your policies:
If this looks like something that you could use, then I suggest that you head over to the
today and create some policies! I suggest that you review the
section of the IAM documentation to make sure that you are taking advantage of the power and flexibility of IAM.
The AWS Management Console now recognizes Users created via
(IAM). IAM users can now log in to the console and manage resources within an AWS account. IAM Users can be assigned individual Multi-Factor Authentication (MFA) devices to provide additional security when they access the console. IAM can also be used to give permission for a particular User to access resources, services, and APIs.
Here's a quick recap of the major features of IAM:
Create User Identities - Add Users (unique identities that can interact with AWS services) to your AWS account. A User can be an individual, a system, or an application with a need to access AWS services.
Assign and Manage Security Credentials - Assign security credentials such as access keys to each User, with the ability to rotate or revoke these credentials as needed.
Organize Users in Groups - Create IAM Groups to simplify the management of permissions for multiple Users.
Centrally Control User Access - Control the operations that each User can perform, including access to APIs for specific AWS Services and resources.
Add Conditions to Permissions - Use conditions such as time of day, source IP address, or protocol (e.g. SSL) to control how and when a User can access AWS.
View a Single AWS Bill - Receive a single bill which represents the activity of all of the Users within a single AWS account.
Put it all together and what's the result? It is now much easier for multiple people to securely share access to an AWS account. This should be of interest to everyone -- individual developers, small companies, and large enterprises. I am currently setting up individual IAM Users for each of my own AWS applications.
IAM is a really powerful feature and I'll have a lot more to say about it over the next couple of weeks. I've got the following blog posts in the pipeline:
A more detailed introduction to IAM.
A step-by-step guide to using the IAM CLI to enable sharing of a limited set of files within an Amazon S3 bucket.
A walkthrough to show you how IAM Users can access the AWS Management Console.
A walkthrough on the use of the AWS Access Policy Language for more advanced/conditional control of permissions.
Let me know if you'd like me to cover any other topics and I'll do my best to oblige. In the meantime, check out the , the , and the
(there's even more documentation ). Also, don’t forget to refer to my on the
for help creating policies that control permissions for your users.
A number of applications and development tools already include support for IAM. Here's what I know about (leave a comment if you know of any others):
- Python interface to AWS.
Cloud management interface (web and mobile).
(Bucket Sharing Wizard).
- Amazon SimpleDB browser.
The AWS Identity and Access team is hiring, so let us know if you’re interested in joining the team:
(SDE-I to Principal levels)
Jeff Barr ():
Jinesh Varia ():
Enter your email address:
Delivered byAlexa Account Linking: 5 Steps to Seamlessly Link Your Alexa Skill with Login with Amazon : Alexa Blogs
Want the latest?
Subscribe to Alexa Announcements
alexa topics
Recent Posts
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 , Sr. Solutions Architect at Amazon.
How Account Linking Enhances Alexa Skills
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 , which provides a secure way for Alexa skills to connect with third-party systems requiring authentication.
Skills that use the
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:
You can map this user profile to an existing user in your user database, using the user_id as key. This would allow you to create a contextual skill that behaves according to your user’s preferences and history. See
for more details and best practices about this procedure.
You can decide what authorizations this user will have in your system.
You can use services such as
to acquire an AWS Access Key and Secret Key to interact with AWS Services such as .
The Basics of Account Linking with the Login with Amazon (LWA) Service
Account linking leverages
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 .
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
(aka bearer token) or an .
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
Account Linking, Step by Step
Follow these steps to configure your Alexa skills with account linking and Login with Amazon.
If you haven’t created a skill yet, please first use the
to build something relatively simple, such as a trivia skill. You can get a prototype up and running in just a few hours and come back here once it’s published.
Step 1: Create a Login with Amazon (LWA) Security Profile
First, you need to create a LWA profile for your Alexa skill. Here’s how.
Connect to
and authenticate with your Amazon credentials.
Click on “Apps & Services”, then “Login with Amazon”
Click on “Create a New Security Profile”
Figure 2 : Access Login With Amazon
Fill in all three required fields to create your security profile and click “Save”. For the purpose of this article, I am using Amazon’s privacy policy URL. Make sure to replace the link with a link to your own Data Privacy policy.
Figure 3 : Create Security Profile
Before you complete this step, be sure to copy your Client ID and Client Secret (see Figure 4) to a text editor so they're easily available. You’ll need these values later in the process.
Figure 4 : Collect Client ID and Client Secret
Step 2: Configure Account Linking in the Alexa Developer Console.
Now that you’ve configured Login with Amazon, you can configure Account Linking for your Alexa skill. (Remember, you need to have a skill already created to do this).
In the Alexa developer console, you might see a 'get started' button for Alexa skills even if you have a skill in development. Press it, then &edit& the skill to get to the configuration screen.
Under the “Configuration” tab for your skill, enable “Account Linking” if it is disabled. Then, enter the following:
Figure 5 : Account Linking Details
The values you need to enter into these fields are detailed in the table below.
Account Linking
Authorization URL
The Client ID received from Login with Amazon during Step 1 above.& This has a format such as amzn1-application-oa2-client-xxx
Login with Amazon supports , for this example, let’s use “profile”.& This will allow your code to retrieve a unique Amazon userid, email address, and full name for the user.
Authorization Grant Type
Select “Auth Code Grant”
Access Token URI
This is the URI the Alexa Service needs to use to exchange an authorization code for a token and to refresh expired tokens.& This is the same value for all Login with Amazon applications :
Client Secret
The client secret received from Login With Amazon during Step 1 above.
The Authorization URL is the Amazon Login URL (/ap/oa).
The Redirect URL parameter tells Login with Amazon where to redirect the browser after an authentication.& In our case, it is the URL provided by the Alexa Skills Kit (ASK) console, labeled “Redirect URL”, and starting with /api/skill/link…
Figure 6 : ASK Redirect URI
The last step is to configure Login with Amazon to accept our redirection URL.& The redirection is URL is given on the Alexa Developer Console, under “Redirect URL”. This is the URL starting by /api/skill/link/…
Copy this value to that text editor I suggested earlier and go back to the Login with Amazon console.
Next to the Security Profile you created in Step 1, click the button with the gear icon and select “Web Settings” from the menu.
Figure 7 : Login with Amazon - Web Settings
Click the &Edit& button in the lower right, then enter the Redirect URL, as it appears on the ASK Developer Console.
Figure 8 : Login with Amazon - Redirect URL
Now you are ready to write some code.
Step 3: Write your Custom Skill Code.
For the purpose of this blog post, I chose to write the Alexa custom skill code in NodeJS and deploy it on AWS Lambda.
You can learn more about writing code for custom skills
When your skill is called the first time, you will receive a JSON document like this:
&session&: {
&sessionId&: &SessionId.7c77f955-ae5e-46f1-a9ca-3fb354b1ce77&,
&application&: {
&applicationId&: &amzn1.echo-sdk-ams.app.fb2fc3e7-55e7-4f05-851e-7ad308a6b499&
&userId&: &amzn1.ask.account.AFP3ZWPOS2BGJR7OWJZ3DHPKMOMNWY4AY66FUR7ILBWAN
IHQN73QHMAHCTVTAHFPUV3WAFNGKBYW5LFUE2WV4CCGEISSPHBHCW5SCYJDL3DLWRRRBB4CQIP3X3PV6
5V2AYMMXSNFPKHPZJFVAH5AHKHDLAER67H3AHL4XBUU76XEH5BGDZZNGV5T6HHAGN6KGZI777J3VA7WGPA&
&new&: true
&request&: {
&type&: &IntentRequest&,
&requestId&: &EdwRequestId.b595d667-caa3-a-c7a31e8adddc&,
&timestamp&: &T15:36:26Z&,
&intent&: {
&name&: &SayHello&,
&slots&: {}
&locale&: &en-US&
&version&: &1.0&
Notice that the “user” section contains a userId properties, but no OAuth access token yet as we did not authenticate our user yet.
Whenever your code receives such input, it should return a “LinkAccount” card, displayed in the Alexa app or the Alexa web site.& The card will contain a link allowing the user to authenticate on Login with Amazon. In addition to the card, it is a recommended practice to return a voice prompt inviting the user to authenticate in the app.
The NodeJS code to generate such an answer might be like:
//if no amazon token, return a LinkAccount card
if (alexa.event.session.user.accessToken == undefined) {
alexa.emit(':tellWithLinkAccountCard',
'to start using this skill, please use
the companion app to authenticate on Amazon');
and the corresponding JSON output looks like this:
&version&: &1.0&,
&response&: {
&outputSpeech&: {
&type&: &PlainText&,
&text&: & Please use the companion app to authenticate on Amazon to start using this skill&
&type&: &LinkAccount&
&shouldEndSession&: false
&sessionAttributes&: {}
Step 4: Test Account Linking on Your Skill.
When you invoke your skill from a device, you will receive a card in the Alexa app asking you to link your account.
Figure 9 : Account Linking Card
Click on the “Link Account” link, and the Login with Amazon page will display.
Figure 10 : Login with Amazon Credentials
Authenticate using your regular Amazon login (the same login used when shopping ).
The very first time, Amazon will ask you if you authorize the Alexa skill to retrieve some data from your user profile.
Figure 11 : Login with Amazon - Authorization Screen
Click ‘Okay’ and a confirmation message appears.
Figure 12 : Success - Account Linking is complete
Step 5: Test the Skill Again.
Invoke the skill again. Now, because your account is linked, an Amazon OAuth Token is included in the input JSON document.
&session&: {
&sessionId&: &SessionId.7fc6aa11-8a2c-4f3f-a1ea-35&,
&application&: {
&applicationId&: &amzn1.echo-sdk-ams.app.fb2fc3e7-55e7-4f05-851e-7ad308a6b499&
&userId&: &amzn1.ask.account.AFP3ZWPOS2BGJR7OWJZ3DHPKMOMNWY4AY66FUR7ILBWANIHQN73
QHMAHCTVTAHFPUV3WAFNGKBYW5LFUE2WV4CCGEISSPHBHCW5SCYJDL3DLWRRRBB4CQIP3X3PV65V2AYMMX
SNFPKHPZJFVAH5AHKHDLAER67H3AHL4XBUU76XEH5BGDZZNGV5T6HHAGN6KGZI777J3VA7WGPA&,
&accessToken&: &Atza|IQEBLjAsAhRBk1-yYVTk9HhZEQnTGL9F3RHS5gIUG0rrerkVvpVTF5k
IFWBvZIx7QtJCkzsRFRf1ZAIZeRz6FJwdeyQCLPEbqLnEKU-zQF4n9x76Dl24Rt7HiltefBilnDm0c2PZQP
_IUBAzcm93CIDxsMYhEmW_Pr0Tm9tIrGzNzVntLgyiUeXmasL1bUOIv_om66ZVwd7urpyiJSoSbA-1NQ
7O9AKC2qXMqvFpvFUBSvgCYoTyyAkOePN63FCaq9NJPYbJLuocqcuyGz9mygNqp9_mNRWRRzcoeSTx
pUoa8LxW-IvVVFEA1omCfXmcVijEZA6nbi-EzheMG7fu1y0XNGPEy40Csq7H07wrSqksz9IDIUd4t
mqiYsJpN4dxfoGddEauC3i4eLCvsg8gbu963CqqUQ3COxgrWKTsqX8AsT8FCFvmfW3IYfhCG6KuPw8
qntBgAU-W9pW523lERQKLxzI07UHyMd2R-Fnaw8IWbBYFCbblwIJhf6twjz9z_4h320f4ywczBa3k_
LCoE0VpidER7rVgBtfreox-XYqV5jw&
&new&: true
&request&: {
&type&: &IntentRequest&,
&requestId&: &EdwRequestId.8-44f7-b271-6b9808d5fba9&,
&timestamp&: &T16:18:57Z&,
&intent&: {
&name&: &SayHello&,
&slots&: {}
&locale&: &en-US&
&version&: &1.0&
Your code can use this access token to fetch the
from the Amazon Profile service API.
var request = require('request');
var amznProfileURL = '/user/profile?access_token=';
amznProfileURL += session.user.accessT
request(amznProfileURL, function(error, response, body) {
if (response.statusCode == 200) {
var profile = JSON.parse(body);
alexa.emit(':tell', &Hello, & + profile.name.split(& &)[0]);
alexa.emit(':tell', &Hello, I can't connect to Amazon Profile Service right now, try again later&);
The code above will return the following JSON output:
&version&: &1.0&,
&response&: {
&outputSpeech&: {
&type&: &PlainText&,
&text&: &Hello, Sebastien&
&shouldEndSession&: true
&sessionAttributes&: {}
Notice the first name, taken out of the Amazon profile.
Keep Us Posted on Your Success.
Congratulations, if you coded along to this point, you have successfully implemented Account Linking with the Login with Amazon service.
Tell us how you’re enhancing your Alexa skills using account linking by tweeting us . For further info, check out our developer pages on
and how to use the
Want the latest?
Subscribe to Alexa Announcements
alexa topics
Recent Posts}