On my site, I want to be able to retrieve whether my own YouTube account goes live. After looking around, I found this endpoint:
GET https://www.googleapis.com/youtube/v3/liveBroadcasts,
that would help me do just that. However, the main problem I found is that it requires an OAuth2 token, and the only way I could find to generate one was going through the whole Login with Google approach.
My main problem is that I want anyone who visits my site, to be able to see whether I'm live or not. I'm not looking for workarounds or using web crawlers either - I want to be able to use this specific endpoint. Is that even possible?
In other words, is it possible to get my own access token manually, and just plug that into the API request to access the endpoint directly? Or is this just impossible?
First thing to know about YouTube Data API is the following: for to issue authorized request to it, one cannot alleviate authentication through the browser.
You may read the doc OAuth 2.0 Flow: Installed apps for thorough info about the authorization flow on standalone computers.
The doc specifies step 4 -- Handle response from Google -- and step 5 -- Exchange authorization code for refresh and access tokens. By the initial OAuth flow, you get two tokens: a short-lived access token and a refresh token that produces access tokens on demand. Authentication without browser is not possible, but once having a refresh token, it can be traded programmatically for access tokens:
Initialization: obtain via browser authentication a refresh token;
Iterations: as many times as needed, query the API for an access token -- without any browser interaction! -- using the refresh token from (1), then proceed further with the call to the target API endpoint (again, without any browser interaction).
Note that the steps (1) and (2) may well be separated such that (1) is executed by a standalone (local) computer that stores the refresh token into a file; later, upon a secure transfer of that file on a different remote computer (e.g. a server that does not have a browser installed), execute (2) on that remote computer, repeatedly as needed
(see Using OAuth 2.0 for server-side, standalone scripts.)
Sounds right:
complete the flow (once) with your own google account,
cache the token server-side, and
include the API’s response when serving your page.
Pitfalls:
How long are OAuth tokens valid for? (The API will start returning errors if this occurs)
How often will the page be generated vs. what rate-limits does the API have? ( you may have to request status at most once per few minutes, and cache the response)
Related
I'm having problems with Get New Access Token for Postman and SmartSheet.
All URLS are prefixed with https:// but StackOverflow would not allow that.
Callback URL: www.getpostman.com/oauth2/callback]
Token Name: Test
Auth URL: app.smartsheet.com
Access Token URL: app.smartsheet.com/token
Client ID: used the one provided when registering my app with SmartSheet
Client Secret: used the one provided when registering my app with SmartSheet
Scope: blank
Grant Type: [Authorization Code]
When I click Request Token it takes me to the SmartSheet Login. After I login and close the SmartSheet browser I get Could not complete OAuth 2.0 Login.
Looking at your example the Auth URL is incorrect. That should be
https://app.smartsheet.com/b/authorize
Also, the Access Token URL should be
https://api.smartsheet.com/2.0/token
The Smartsheet OAuth2 flow also requires a Scope, so it can't be left blank in spite of what Postman says.
More information on all of this can be found in the documentation:
http://smartsheet-platform.github.io/api-docs/#oauth-flow
It is important to note that with all of this set correctly setting this up in Postman still won't work. This is due to the fact that the Smartsheet process of obtaining and refreshing the token Smartsheet requires clients to hash the authorization code (with a pipe and the app secret, using SHA256) rather than sending it in clear text. This is arguably non-standard, but is still within the OAuth2 spec. More information on this process is at the documentation I referenced above.
Unfortunately, it does not look like Postman supports these types of deviations from "vanilla" OAuth2. Depending on what you are trying to accomplish, you will either have to go though the steps of the process manually, or stand up a third-party app in a hosting environment. If you are simply looking to generate a token, this approach http://smartsheet-platform.github.io/api-docs/#direct-api-access may work for you instead.
If you are trying to test in Postman the Direct API approach works. http://smartsheet-platform.github.io/api-docs/#direct-api-access
Step 1) Go to your actual smartsheet "https":"//app.smartsheet.com/b/home" and under Account>Personal Settings>API Access -- Generate a token (copy it you wont be able to copy after you close)
Step 2) Get the url for your sheet. Right click on the sheet name tab and select Properties. Copy the the Sheet ID (ie 123456). Add it to the end of the url: "https":"//api.smartsheet.com/2.0/sheets/123456"
Step 3)The most confusing one in my opinion. In Postman select No Authorization. Then go and update the header with "Bearer 0da6cf0d848266b4cd32a6151b1". You have to have the word Bearer and the randomly generated string of numbers is from Step 1.
Then send the get request and you get your sheet back in json format.
Actors
Front-end (fat client-side Javascript application) which has Facebook access token.
Back-end which 100% relies on OAuth2 authentication. All requests need to be authenticated via Facebook.
To mutate user data on the back-end, I require user to be logged in via Facebook. Ideally, with every request, I would know the Facebook's user ID (the one that graph.facebook.com/me provides).
Question 1
Is there a way to get whatever graph.facebook.com/me returns to be signed, so I don't have to call Facebook to verify it with every request, nor store state in my backend?
Situation 2
If the answer to Question 1 is "no", it means I have to invent my own. I am thinking of the following:
The user sends the access token to the backend.
Backend calls token debug API, signs the result with my key, and sends back to the client.
Every time client does a request, it includes the previously-included blob.
Upon every incoming request to the backend, it verifies the signature, which, if matches, means that the request wasn't tampered with and I can trust it is coming from the previously-verified token.
Question 2
If I employ this scheme (sign the answer from Facebook and send it upon every request), how can I safely implement this? Are there resources I could read up which would tell me:
Things to be cautious about with this scheme.
Which signature algorithm to use, how to safely verify the signatures.
How to avoid common types of attacks and stupid mistakes.
Thanks!
It's not really clear what exactly you want to do, but I think you should have a look at the docs at
https://developers.facebook.com/docs/graph-api/securing-requests
Quote:
Graph API calls can be made from clients or from your server on behalf of clients. Calls from a server can be better secured by adding a parameter called appsecret_proof.
Access tokens are portable. It's possible to take an access token generated on a client by Facebook's SDK, send it to a server and then make calls from that server on behalf of the person. An access token can also be stolen by malicious software on a person's computer or a man in the middle attack. Then that access token can be used from an entirely different system that's not the client and not your server, generating spam or stealing data.
You can prevent this by adding the appsecret_proof parameter to every API call from a server and enabling the setting to require proof on all calls. This prevents bad guys from making API calls with your access tokens from their servers. If you're using the official PHP SDK, the appsecret_proof parameter is automatically added.
Inching closer...
I am building a contacts synchronization facility into our product (with PHP/javascript). We are using an incremental approach for access - initially requesting a base set of scopes, then we want to expand these scopes when (if) our client decides to use the extra facility.
Base set:
www.googleapis.com/auth/plus.login
www.googleapis.com/auth/plus.me
www.googleapis.com/auth/userinfo.email
Extended with:
www.google.com/m8/feeds
www.googleapis.com/auth/contacts
I can get the extra scopes using the gapi.auth.signIn() call, but that doesn't seem to give me a "permanent" access token to use - later requests to the API in PHP don't show the new scopes. Does that mean I have to have an explicit call to the gapi function any time I want the frontend to access contacts?
Also, how do I get an offline token that I can use for the background process that will do the synchronization? Do I have to have a separate token for offline access? Can I mix offline and online access using the same token, or do I have to have one of each?
thanks,
andy
The difference between both online and offline access is that when you request an access token, this token will expire after certain time, usually 60 mins. After it expires the user will have to provide again the credentials so you can receive a new token.
In this case it is an "online" token.
When requesting the access token and you provide the parameter access_type=offline you will receive a refresh token. After the access token expires, you can request a new request token using the refresh token so it is not necessary that the user provides again the credentials.
Here you can find more information about that: https://developers.google.com/accounts/docs/OAuth2WebServer#offline
hope it helps.
My app got white-listed for using the Ads API.
I was wondering in regarding to the authentication flow.
Say, that I need to retrieve and execute actions via the API on daily tasks ( with no user interaction) , I find the authentication process quite cumbersome.
Is there a way to work with my app access token instead of a user access token?
I want to be able to approve my app only once for each user and then to be able to work with no user interaction.
Can I achieve this?
App access token is not relevant for this case.
I had to work with the user access token.
I followed this doc: https://developers.facebook.com/docs/reference/ads-api/
Eventually , one should use some client side code in order to get a user permissions and then make another request for getting the user token.
So you'll have to call
https://www.facebook.com/dialog/oauth?client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&scope=ads_management,offline_access&response_type=code
Get the authentication code and make another call:
https://graph.facebook.com/oauth/access_token?client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&client_secret=YOUR_APP_SECRET&code=AUTHORIZATION_CODE
Then you'll get an access token which is valid only for two months, in opposed to what Facebook docs says in here:
https://developers.facebook.com/roadmap/offline-access-removal/
"Ads APIs are special cased to allow collection of statistics offline. PMD partners should use server-side OAuth flow in order to receive a non-expiring token rather than a token that has longer expiration time."
Too bad that the access token is not really valid forever...
According to "Exception 4" in this document , if you have Ads API access you should be able to get a non-expiring token if you use the correct workflow. Following the guidelines outlined here, if you use the server side OAuth flow, to make the following request you should get a non-expiring token:
GET /oauth/access_token?
grant_type=fb_exchange_token&
client_id={app-id}&
client_secret={app-secret}&
fb_exchange_token={short-lived-token}
thx for the feedback regarding the Access token process being cumbersome. Because this is a one to many solution - a single App ID can manage multiple ad accounts, on behalf of multiple people - we need to make calls on behalf of people.
You should be able to get a persistent access token for Ads API. If you are not getting it, please provide exact steps you are following so we can see if there is a bug or you might be missing a step.
Thx.
Facebook has two flows for Authentication, client-side and server-side. When should each one be used?
Facebook docs: https://developers.facebook.com/docs/authentication/
Possibly related: What is the purpose of the implicit grant authorization type in OAuth 2?
Depending on your needs you can use one or the other or both. If you want calls to facebook to be processed before the user sees a certain page then use server side... however if you want to display partial information until the user has authenticated, use javascript authentication.
It boils down to this:
Javascript authentication can happen with-in a popup window and does not require a page reload you can also just perform a top.location.href redirect.
PHP authentication involves a redirect to an authentication page.
Also see this thread, in particular this response.
To add to #Lix's answer, I would say:
Client Side Authentication
When you want some information from Facebook API about the user that is required once, as in you only need to get it once like the user's name and email.
When you want to temporarily access/manage the user's information/data and don't need to do it often.
You get a temporary token, which is valid only for a few hours and you need to get a new token to call the Facebook API again after it has expired (which requires the user has to grant permission again).
Server Side Authentication
You want to manage the user's data (on their behalf) after the user has left your website/app. Example, gathering the user's feed/timeline data on a regular basis.
When you want to access/manage the user's information/data in a recurring fashion untill the user hasn't revoked access to your client id (represented by a Facebook app).
You get both a temporary token and a permanent token (which lasts for about 60 days at the time of writing this). You can get a new temporary token by using the permanent token every time you need to call the Facebook API (given the previous temporary token has expired) -- without bothering the user to grant permission again.
So, in short, for short term use, follow client-side authentication flow and for long term use follow server-side authentication (given you have a backend server of your own).