I am trying a post-call to generate an access token using the client username and password. I would like to know how we can achieve this through Node Js Code.
Generally speaking, access_token are rattached to the OAuth2 authentication framework, which doesn't require the application owner (you) to have access to one of your user email/password. This is a more secure approach that is broadly adopted.
The way OAuth2 works on the Google Calendar API is a 3-parties (or 3-legged) authorization. Let's take the example of a user that browses your website and want to sign-in using its Google Account. The steps to authenticate him are the following:
The user clicks on "Sign-in with Google"
The application owner (you) performs a request to Google saying that a user wants to connect (that's the OAuth consent screen)
Google replies by giving you a URL (authorizationUrl) where to redirect the user
On that URL, the user is prompted with several information about your application and can grant access.
When the user has granted access, Google will redirect the user to your application success page (callbackUrl) with a unique code.
Using that code, the application can retrieve an access_token, which temporarly lets your application performs requests on behalf of a user.
These steps are a rapid overview of the OAuth-flow, also known as the OAuth dance. To make POST requests to the Google Calendar API, you will have to perform that OAuth dance for every single of your users.
Implementing that flow can be tricky. Fortunately, Google gives very helpful documentation on that. If you don't want to bother, you can also use API-tools (like Pizzly) that takes care of that for you.
Related
I'm in the process of building a Google Chrome extension, and have some questions about how to implement security into the application.
I need to access a couple of Google API's so am going to be using OAuth 2.0 for that. So basically from the extension I know which user is logged into the browser.
My extension then needs to get and post data to my (nodejs) API service. I want to ensure that the user requesting data is the same user that is logged into the browser. Is there any way of using the previous Google authentication process to also authenticate communications between the extension and my API? I dont really want the user to have to log in again, to access my API.
I'm sure I'm missing something simple, and I've not been able to find anything that fits this scenario
Follow the OpenID Connect auth flow and you will get an access_token and an id_token. The acess_token you will use to use to make authenticated requests to Google APIs as usual. The id_token will be used as authentication with requests to your server.
When the requests hit your server you will need to validate the token and you can then use the contents of the id_token to identify the user.
User wouldn't have to login on auth process provided if user is already logged in and you are using a web application flow (not chrome.identity APIs) but user would see the consent screen atleast the first time. However you can skip the account selector screen if you already know the email address by providing &login_hint= parameter.
I'm trying to post to my company page directly from my server, but I have a hard time understanding how the authentication works. All examples + the documentation seem to require you to have a callback where the "visitor" is promted with a form to confirm the access. But in my case, my app is supposed to only post to my company page and I didn't plan on building a gui at all.
I have setup the Client Id and Client Secret in the Linkedin developer section.
Even though you are the only one that's going to use the app, you still need to execute the OAuth flow and therefore authorize your own app to use your account. You can use Grant for that.
Another thing to note is how LinkedIn handles scopes. They changed how the permissions work earlier this year, so for certain permission you'll have to submit your app for approval.
Lastly LinkedIn doesn't give you a refresh_token so in order to refresh your access_token once it expires you'll have to use a similar hack as the one I described here for Facebook.
I am currently creating an API (who isn't) however when I look for a way to use oAuth in the ways Facebook and twitter do to authenticate users trying to get data all i find is a way to get users permissions which I do not need, the idea of my implementation of oAuth is to authenticate the developer so when they make an API call the server knows who they are and what to serve them. I haven't tried any oAuth code because I haven't found node module that will help so far, however I can give background. I am using:
Mongoose, to query MongoDB
Express, for the HTTP Server
I do not explicitly want to use oAuth, I simply thought it was a good idea, I am open to any other way of doing things.
I think you should read the OAuth specification and to decide if one of the grant flows suits for your requirements. When user(developer) logs in you grant Access Token to him/her. Now on when user makes request to API the Access Token must be on HTTP request header, extracting that Access Token on back-end service from the request you can identify the user.
It is up to you what kind of information you store to DB from the user when she/he registers to your service. But all that information can be mapped with the Access Token that user gets after succesful login or stored inside the Access Token also.
I have the following elements:
A PHP back-end providing a RESTful API secured with OAuth (FOSOAuthServerBundle with Symfony 2)
A Javascript front-end (AngularJS), i.e. an OAuth client.
My goal is to provide users with an authentification page in the front-end, allowing them to log in and access the API through the Javascript.
I do this the following way, according to this article: http://www.bubblecode.net/fr/2013/03/10/comprendre-oauth2/ (unfortunately in French, but if you scroll a bit, the diagrams explaining the standard grant flows are in English):
I provide a form asking the user credentials (login and password)
I use an OAuth Implicit Grant to exchange the user credentials for an access token.
Evertything should work (almost) well so far.
Now, the reason of this question is I want to add Facebook Login to my front-end. What this will give me is a Facebook access token each time a user registers with Facebook Login on my front-end. Ideally, my back-end should:
get this token
check it against Facebook PHP API in order to validate it
retrieve from Facebook PHP API the user Facebook UID
compare it to the ones of my app registered users
return an access token (this time for my own app, not Facebook) if and only if the Facebook UID matches with one of my registered app users.
My question is: which type of grant should I use to make the transaction between my front-end and my back-end in such a use case (given that it is of course not acceptable to give my Client Secret from a Javascript Client)?
Actually, I managed to found the solution. A custom grant should be designed to solve this problem, based on the Implicit Grant (in which the Client Secret is not asked).
However FOSOauthServerBundle does not yet implement grants based on public clients (see https://github.com/FriendsOfSymfony/FOSOAuthServerBundle/issues/266 for more details).
When I call an oauth provider like gmail and I get the token back, how can I make sure that all future calls I make are from that same client that did the authentication? that is, is there some kind of security token I should pass pack? Do I pass that token back everytime?
For example, if I have a simple data table used for a guest book with first,last,birthdate,id. How can I make sure that the user who "owns" that record is the only one who can update it. Also, how can I make sure that the only person who can see their own birthday is the person who auth'd in.
sorry for the confusing question, I'm having trouble understanding how azure mobile services (form an html client) is going to be secure in any way.
I recently tried to figure this out as well, and here's how I understand it (with maybe a little too much detail), using the canonical ToDoList application with server authentication enabled for Google:
When you outsource authentication to Google in this case, you're doing a standard OAuth 2.0 authorization code grant flow. You register your app with Google, get a client ID and secret, which you then register with AMS for your app. Fast forwarding to when you click "log in" on your HTML ToDoList app: AMS requests an authorization code on your app's behalf by providing info about it (client ID and secret), which ultimately results in a account chooser/login screen for Google. After you select the account and log in successfully, Google redirects to your AMS app's URL with the authorization code appended as a query string parameter. AMS then redeems this authorization code for an access token from Google on your application's behalf, creates a new user object (shown below), and returns this to your app:
"userId":"Google:11223344556677889900"
"authenticationToken":"eyJhbGciOiJb ... GjNzw"
These properties are returned after the Login function is called, wrapped in a User object. The authenticationToken can be used to make authenticated calls to AMS by appending it in the X-ZUMO-AUTH header of the request, at least until it expires.
In terms of security, all of the above happens under HTTPS, the token applies only to the currently signed-in user, and the token expires at a predetermined time (I don't know how long).
Addressing your theoretical example, if your table's permissions has been configured to only allow authenticated users, you can further lock things down by writing logic to store and check the userId property when displaying a birthday. See the reference docs for the User object for more info.