Currently, I am working on linking my Alexa skill with my website. I'm stuck. I've followed YouTube tutorials and looked at the documentation. I basically want users to click on the account linking button, be taken to a login page and then have that authorize the users with their own private data. Do I need to create a oauth server? Is there anybody I can talk to who has already done something like this? I created a html page to log users in using an api call but I haven't gotten any further. Any help is appreciated.
There are two questions that you asked here. Addressing them consecutively:
Do you need to an OAuth server for account linking? --> Yes. You either create your own authorization server which uses OAuth2.0 or you can rent it from providers. There are various OAuth server providers like auth0, okta etc.
If you have created an html page for login, then it needs to connect with your auth server in the backend and you need an API to do that as well as connect with the LWA server to complete account linking with Alexa.
The auth server will basically generate an auth code upon authenticating the user and subsequently it will generate an access token. Both these URLs must be mentioned in the Amazon Alexa developer console.
Then you need to make the calls to LWA to complete authentication with Amazon. This will generate an LWA auth code and subsequently an access token.
This LWA access token along with user auth code generated by your auth server will be used to enable the skill from your website.
Feel free to contact me if you have more queries! Good luck.
Related
I'm trying to get my head around OAuth from the context of having an API that I want to secure and a javascript based single page app made in Vue.js that will consume this API. I've been told that OAuth is the industry standard for this type of thing.
I want to let other clients like a mobile app also use the same API.
From what I can gather the right flow is Authorization Code Flow with Proof Key for Code Exchange (PKCE) https://oauth.net/2/pkce/
The bit I am confused over is how I seem to need to get users to approve access. For example you don't have Twitter saying "Would you like Twitter to use Twitter". If I was in the position of people using the account to create another account I wouldn't have any confusion but when the client is your own website what is supposed to happen?
I can sort of imagine that I could automatically approve the website or just bypass the part where the user approves but then I feel like I'm going off script. Then I think to myself, have I completely got the wrong end of the stick- is OAuth not designed for this?
If anyone can see where my ignorance is I'd be more than happy to be corrected!
Thanks!
OAuth and OpenID Connect enable you to authenticate users in many ways, for web and mobile clients. Each app implements a code flow and redirects to an authorization server (AS).
Each client is configured with an entry in the AS, and consent can be disabled when required. It is typically only enabled when personal assets are involved. Eg to grant a security code scanning service access to my GitHub repositories.
From asking around a bit and reading a bunch more found searching for "first party" providers: it is okay to just have the main website bypass the bit where they approve access and just send over the token.
I'll try to connect to the content api for shopping via API.
I'de tried some different oAuth ways (e.g. "three-step-method" with access key and baerer-token) but for a spezific integration I need the "credentials-oAuth".
Currently I tried as following:
https://accounts.google.com/o/oauth2/v2/auth?
client_id=[my client id]&
scope=https://www.googleapis.com/auth/content&
redirect_uri=[some random request bin -> added in Authorised redirect URIs ]&
response_type=code
If I call this via Postman, I'll be redirected to the login page of Google. But why?
How can I solve this problem?`
BG
David
Shopping API data is private user data. In order for your application to access private user data it must have the permission of the user who owns that data.
We use OAuth2 to do that. The user must consent to your application accessing its data. In the below image the application Google analytics windows is asking the user for permission to access their Google analytics data.
If I call this via Postman, I'll be redirected to the login page of Google. But why?
You are seeing a login screen with Postman is simple the user needs to be logged in before they can grant access to their data.
How can I solve this problem?
You dont as there is no problem the user must login to grant your client application consent to its data. This is working exactly as it should
Service accounts
Update to answer comment Service accounts are special Google accounts that can be used by applications to access Google APIs programmatically via OAuth 2.0. A service account uses an OAuth 2.0 flow that does not require human authorization. Instead, it uses a key file that only your application can access. This guide discusses how to access the Content API for Shopping with service accounts.
I'm trying to setup account linking in dialogflow agent using this documentation, I've created my credentials from the Google cloud platform. when I'm trying to put that credentials data to Actions on Google console, it gives an error as shown in below picture.
I've put these Authorization URL and token URL from my credential JSON.
The error says: Google accounts cannot be used as Auth endpoint urls per our Account Linking policyLearn more
I want to know about the following:
What this error means.
how to solve this issue.
The error is exactly what it says - if you are setting up Account Linking using the Auth Code Flow, you're not allowed to use Google's servers as your authentication endpoints. You're expected to have your own OAuth server (or use one such as Auth0) to do this.
How to resolve this depends on your exact needs and exactly what you have available to work with:
Setting up your own OAuth server
If you have an existing service that has accounts already, you would likely want to link the user's account in your service to their Assistant account.
To do this, you would need to setup an OAuth server. If you are already using one as part of your existing service, you can configure it for the Assistant. If not, Google provides information about the minimal implementation requirements or you can use existing libraries.
Using OAuth as a Service
You can also use a service such as Auth0 to provide authentication. Depending on your needs, this is a good service that allows people to log in using a range of providers and gives you an API to access their accounts maintained on Auth0.
Using Google Sign-In for Assistant
Finally, if you are either using their Google Account in your own service, or you just want a way for them to log in using their Google Account, you can use the (still in preview) Google Sign-In for Assistant. This will give you an ID token as part of your fulfullment which contains the Google ID
At my company we are developing several web applications that uses a REST API server.
First a little introduction.
The app provides the ability to manage users through the REST API and allows the users to login to the app.
Right now the REST API is for internal use only because we plan to develop more apps and communicate to the REST API as the central point of data access. We are handling the REST API authentication with a "Resource Owner Password Credentials Grant" implementation for the internal apps.
What we need is a Single-Sign on service for all the apps, we want a user to login to an app and if he/she access to another of our apps he/she will be already loged in.
We have been experimenting with the CAS protocol, with the CASino library specifically and it works great.
The problem is we don't know how to handle the flow between the apps, the REST API and the SSO service, also I don't know if there is a better choice regarding SSO services.
My questions are...
How we could handle the flow between the apps, the REST API and the
SSO service, because the REST API should be stateless it should not
communicate to the SSO service? or is there a way to communicate the
REST API to the SSO service?
Is there a better choice to implement a Single-Sign on service,
maybe OAth or OpenID and are this options suitable for REST APIs?
Thanks in advance!
Your REST API will have to talk to the SSO server to validate the Access Token, unless all the information it needs is encrypted inside the Access Token. Not sure what you mean by "flow between the apps", you should have all apps talking to a central SSO server.
When a user wants to create an account on WebApp1, the account should be created on the SSO server, either by redirecting them there or if you need a differently styled signup form for each web app, then via an AJAX call to the SSO server's REST API. I would recommend the latter as redirecting is more difficult to debug and it can make a bad user experience.
Make sure the messaging is clear, i.e. not "Sign up for a WebApp1 account", but "Sign up for a MyCompany account to get access to WebApp1".
OAuth 2.0 is very popular and people have more experience with it, so it's easier to get help or integrate with apps created by others.
The doorkeeper gem is a good server library.
OAuth 2.0 is normally used when the SSO server doesn't trust the client apps (e.g. Facebook, Twitter), but it can be implemented in such a way to skip the client authorization step (where the user is asked to approve the client app), and you can use the Resource Owner Password Credentials Grant via a REST API.
CAS is easier than OAuth. It is fairly easy to implement the basic endpoints and that way you can customize it as you wish.
I worked on a CAS-based server with a custom implementation (not sure if it was even really CAS-compliant). The authentication was done with Devise (I don't recommend Devise if you're going to customise it a lot, make your own in this case). The original flow was that the user went to the website, clicked Login/Register and then was redirected to the SSO server and after the user logged in, redirected back with a one-time ticket that the website's backend exchanged to an access token via a REST API call.
Then we added a REST API that was called from each website with AJAX. You send the username/password/captcha/etc and get back an auth token, which the site sends to its own backend. The SSO REST API can also set a cookie on its own domain, so that if the user visit another of our web apps it makes a call on pageload to check if the user is logged in. This way you're automatically logged in on every webapp without the redirect mess.
All tokens issued + the associated user info were sent to a fast Node.js app that would save them to Redis, and the app backends would call this app to validate the access tokens really fast, without putting load to the SSO Rails app.
I've made an app who use OAuth from Google to access to Google Sites API. It works perfectly, but I want less user action, especially the first time when you must accept google's permissions, get authorization token, to get access and refresh token.
I want to know if it's possible to avoid all this steps (for users, and do this behind the application), in the code with HTTP requests for example or google libs, and just have to inform a google account (mail/password) to get an access/refresh token.
Have you any tips or knowledge about this ?
Thanks by advance
As i was using google analytics api i made some research and the minimum process is:
user click authenticate link on your web page, then is redirected to external google webpage when is prompted securely for login and password. and nothing else.
This oauth refresh token you can automate then - read about this in google docs - there is some info about this. i made all by changing a little simple hello world analytics app from google code.
As i remember You had to know what class in php is, and changing oauth wrapper in simple apps. It can store and process refresh tokens automatically - user needs to enter login and password as i said but it can be stored in cookies, so made once.