I'm experimenting with the idea of adding Account Linking to a skill, using only S3 and Lambda, and then having my skill be in Lambda. The flow would go like this: 1. The login url would point to an S3 bucket's public https url 2. That would be static html with a login form 3. The login form information would be submitted via ajax to the Lambda function, which is mapped to a API Gateway endpoint 4. The authentication Lambda function would store the user credentials in DynamoDB and return a generated Token 5. The static login page would then redirect to Amazon's "success" callback url 6. The skill would be developed in Lambda, hitting the same DynamoDB that the login function did, allowing lookup of the token and retrieval of the user's credentials My first speed bump was cross-domain requests. Since the S3 url and Lambda url are on different sub-domains, the browser prevents the ajax call. I fixed that by adding CORS headers to both the S3 bucket and the API Gateway (which was a huge PITA!). I think that this concept will work, allowing an entirely AWS-hosted skill with custom authentication. But before I go much further, has anyone else tried this and run into problems? Can anyone think of what might go wrong? Is this a valid way to use account linking?
Sounds plausible. I hit CORS headaches two days ago on work-related stuff. One question is if you are hosting static html somewhere, is there any reason not to put most of the stuff there? It's got to be easier than writing it all in a Lambda function. If you do get it all to work, do you want to write a chapter for my book? :-) I need an account linking chapter and I just haven't had time to get to it yet. I'll eventually need account linking for my skills. But I'm waiting to see if Amazon actually ever publish them before I put any more work into them. (Since people seem to have already received notification for skills going public tomorrow, I guess I'm not in this week's pick either. Grumble.) However I'd rather keep it all on AWS for now, if possible.
My goal is to NOT host anything on a web site anywhere, and instead keep everything on S3/Lambda. For one skill I want to work on, the only thing I need from the user is their user id/password for an external service, so I can login on behalf of them. So I don't need a web site at all, I just need a login page for account linking. And I can use the built-in amazonaws-hosted domain for that, to keep everything in the cloud with nothing for me to manage! If I do get it working, I'll write something about how I did it. But no, I don't want to write part of a book. I've already got more to do than I can even begin to get to. :)
Matt, Sounds like a good idea, any further luck with it? I've reached the point where I'm going to need to add some sort of account linking in order to added value to the current skill I'm working on. I think I'll try out your approach--will keep you posted on how it works. Not quite sure of my timeline, though. Hoping to make some progress over the next month, but with the holidays, may not get very far until 2016! Side note, wonder if there's a way to monetize this way as well? If a small one-time payment could be collected to perform the linking? Take care, Mark
Yes, I did in fact get it working well. See this thread:
https://forums.developer.amazon.com/forums/thread.jspa?messageID=24961 It's actually not that difficult to setup. The hard part really is the AWS environment. I'm not sure if it's possible to monetize at the linking stage. I guess you could capture the user's payment details right there and process them. That would work. But I'm not sure if it would be possible to take payment through external sites like paypal or even amazon payments.
Mark, One difficulty with monetizing skills now is the new user id system. Every time the user disables/re-enables the skill, she's going to look like a new user to you. So you'd have to set up some system to track the users who have paid that isn't dependent on their user id. So, you wouldn't just be able to have the user "click through" some payment buttons, capturing what you need along the way. I also suspect that certification might his a road bump if you tried to monetize the skill. Steve
If you are using linking, you don't care about the userId anymore, because you have the token. If they disable/reenable, you can use their authentication to give them back the same token they had before.
Understood. I was just saying that with the new system you'd need a way of keeping track of users other than user id, whereas before you could simply capture the user id and associate *that* with payment information. Now, to keep track of users through linking, you need some sort of authentication system. Steve
Steve, isn't the whole point of account linking to link to an account? I think it is assumed that you already have a user identity management system and that you are linking up the Alexa user with that. Personally I'm trying to hold off from using the account linking feature until they come up with a sane way of account linking to "Login with Amazon". I can write a whole identity management system, sure. (Day job has me hip deep in Openstack's keystone!) But I'd rather spend my time writing my application, not a service. Especially when Amazon already provides one. Alexa is not an identity management system and it doesn't make sense to expect it to operate as such.
I hope at some point they will allow skills to have an option to link to the user's Amazon identity. If the user wants to enable the skill, they must agree to provide this information to the skill. Then, along with the skill request, the JSON would contain some basic information about the user, and perhaps a token to access more detailed information about them. That way, you can uniquely identify a user and maybe some demographic stuff, so you can customize their experience, all without having to maintain your own identity system.
Yeah, that's a natural assumption. And, maybe I'm thinking about this wrong, or just thinking of a case that doesn't matter in practice. But you seem to need account linking in some cases even when you don't need the user to authenticate anything on *your* end, but just want to hang on to some information, or them so they can access some *other* service. Think of Matt's IFTTT. *He* didn't already have a system that he was linking the user to (I'm assuming), nothing on his end he needed the user to log into, and so didn't need the user to authenticate anything with him. He just needed to associate an IFTTT key with a user id (or linking token.) In a way, it's more like a "favorite color" skill, just instead of needing to associate a favorite color with a user, it's an IFTTT key. But this sort of thing does require account linking. (Similarly, I had had my skill Quick Events certified before account linking, but later had to add linking when they introduced the feature.) So, you're absolutely right....you are indeed linking a user to an account. But, not an account that you control, or that you would otherwise needed to have set up authentication for. Now the point about monetization: under the old system, you *could* have pretty easily tracked who paid for a skill via user id, without setting up an identity management system on your end, by tracking the user id. Under the new system, you'd need to add an identity management piece to do that, even if it weren't otherwise needed. But I'm with you. I'm hoping they'll give us a way to this soon.