I created a web application which will show all private videos of only one account.
Now I have to authenticate the account to get list videos. I saw 2 ways to authenticate by ClientLogin and Oauth. Which ClientLogin is deprecated and don't know how to use Oauth to authenticate the default account on server.
I have client_id and client_secret for my app.
I try this example but not working and i don't know what in $get['code'] and how can I put username and password of this account when using OAuth not ClientLogin.
It's pretty simple.
You can follow the steps at How do I authorise an app (web or installed) without user intervention? (canonical ?) to get a Refresh Token. At Step 8, choose the YouTube API instead of Drive API. Try to choose the most restrictive scope, eg. readonly. You can embed the Refresh Token (securely!!!!) in your app and then use it at any time to generate an Access Token. Thus the stored Refresh Token behaves like a username/password with restricted permissions.
Ask you have stated clientLogin is shut down you can not access any Google api using Login and Password. Your application needs to be authenticated
The thing you need to know about the YouTube API is that it does not support service accounts. You will have to use Oauth2. I am not a PHP developer but I have done this previously in C#. What you want to do is possible just a little tricky.
First off as I said you need to use Oauth2. I am hoping that this example is reasonably up to date if not the one for Google analytics is you may have to compare them a little.
Your script will need to be authenticated once using Oauth2. Then by requesting
$client->setAccessType("offline");
you will receive a refresh token. You will then be able to use this refresh token in your script on the server at anytime to request a new access token and access YouTube for that channel.
Related
I am creating an application which aims at automatically creating Spotify Playlists in a central Spotify account (not the account of the end users).
I have set up this account and created the developer app for the secret and the client_id.
On the backend side, I am using PHP to authorize this central user, and it is working as long as I am logged in myself with that account.
Users that visit my website should be able to create playlists via that interface through the Spotify Web API without the need to authorize their account nor being logged in at all.
If I'm trying to open the same page on a separate device (without having any account logged in), it just gives me the following error:
User not registered in the Developer Dashboard
Is it somehow possible to perform this authorization process only on the backend side without the need for the user to authorize it?
Eventually, I want to send the playlist URL created in the central Spotify Account to the user who can open it in their own app or share with others, if they want to.
I try to avoid that multiple users must authorize for my app, since I don't need to access personal information from their account, anyways.
I used the 3-step process for authorization as described in this Stackoverflow Post: Spotify oauth2 with PHP curl. How to get authorization code?
If necessary, I will provide more information.
Do you have any idea, how I can implement this authorization process for the single account on the backend side, without the user even showing any authorization process of the Spotify Web API at all?
EDIT1: I am not trying to login on the behalf of my users, just automatically for my own account without the interactive login with Spotify. Is that even possible?
I received valuable feedback from the Spotify Developer Community that helped me finding a solution to the problem.
When you let the central Spotify account login to your app, you'll [get] an access_token (that will expire in 1 hour) and a refresh_token.
When the access_token of that account expires, let your server send a POST request to the Accounts service /api/token endpoint, but use the refresh_token in place of the access_token.
A new access_token will be returned.
A new refresh_token might be returned too. (I don't think that's even needed)
You can read more about it here.
My web using the PHP Google_Client to insert the youtube playlistItem in my playlist (2-leg-oauth),
and get the error
Client is unauthorized to retrieve access tokens using this method.
Where can I setting the server using my-account#gmail.com to have the same permission to access google api
such like insert playlistItem,
or is there having another way without using my-account#gmail.com to get same permission?
PHP Code:
putenv('GOOGLE_APPLICATION_CREDENTIALS=client_secret.json');
$client = new Google_Client();
$client->useApplicationDefaultCredentials();
$client->addScope('https://www.googleapis.com/auth/youtube');
$client->setSubject('my-account#gmail.com');
If you have delegated domain-wide access to the service account and
you want to impersonate a user account, specify the email address of
the user account use
$client->setSubject($user_to_impersonate);
The YouTube API doesn't support delegated domain-wide access or service accounts. You will need to authenticate with Oauth2.
see PHP Code Samples
You're hitting a common problem. Many developers think that a Service Account is the correct way for server apps to communicate to Google's API services for a given Google account. It isn't! A Service Account, as its name implies, is a brand new account (actually a kind of half-account since you can't actually log in to it) that is dedicated to your app.
What you need to do is a one-time procedure to generate a Refresh Token, which you will store securely. Thereafter, whenever you need to access a Google API such as YouTube, you will use that Refresh Token to generate an Access Token, which you will include in each API request. The steps are enumerated How do I authorise an app (web or installed) without user intervention? (canonical ?) and https://www.youtube.com/watch?v=hfWe1gPCnzc
I'm currently trying to wrap my head around a rather complex OAuth2 use case. I have two servers, one is a client side web server, which serves a website, the other is an API server, which is used to interface with all our backend data.
Currently users use a basic UserCredentials flow which creates an access token on our API server, which is then used to sign all requests from the webserver to the API
Is there a way I can allow users to log in using Google or Facebook, and either use the access token generated to sign API requests in the same way as above, or alternatively create an access token on our API which is then used the same way as above?
In a word: NO.
Let me try and explain why. Lets start by looking at Google, to access google you need to register your application in Google Apis console. When you ask a user to give you access to there google data you do it using the client id and secret you got from apis console. Then google goes about createing your application an access token for there api this info is all stored on there servers. When you then try and use that access token they know which user gave you access to there data via the api.
Now the same holds true for Facebook, and your service as well. They are all diffrent APIs offered by diffrent companys. They create the Access tokens Google cant create you an access token to access data on Facebook any more then Facebook could to Google. Things just dont work that way.
I'm trying to implement a transient oAuth authentication for a web app I'm creating. Essentially, the user needs to login with the Service each time they visit my web app. Primarily it's to enable using the web app without me having to store any of the user's authentication data. I'm trying to use the Tumblr API.
My platform of choice is PHP. However I've never really worked with oAuth before and and am still learning. The following scenario illustrates what I'm trying to achieve:
The scenario assumes that:
The user has already authorized my application in their Tumblr account.
Using my Tumblr Consumer Key, Tumblr Consumer Secret, I call to get request_token, which I later display to the user via a link.
Now on clicking the link above, I expect Tumblr to NOT to ask user to allow the app again (authorize in their account) and simply redirect user back and returning some info that will allow me to distinguish the user. There is no $_SESSION as user is trying login to the website using Tumblr
Is this even possible? If yes, can you help me figure out how to get this done?
Ps. I'm a complete oAuth Noob so please be gentle :)
If you are trying to use Tumblr in a way similar to Facebook Connect, Tumblr does not offer this feature at the moment. ie: you can not use Tumblr to log into your site.
Tumblr's OAuth implementation will allow you to have the user allow access for your app to the users account indefinitely. Which means that your app will always be able to access the users account, whether they are logged into your site or not. They will still have to log into your site each time they want to access your app.
Here is a solid guide to OAuth. Tumblr uses OAuth 1.0 :
http://hueniverse.com/oauth/
Twitter'll phase out HTTP basic authentication by August 2010. In the link my scenarios are from Desktop Applications. Basically my client should tweet new posts on a website.
This would be incredibly simple with HTTP basic auth, because I can store and use my account's username and password in the app to authenticate.
However, with OAUTH I can get final credentials by two means:
Callback method. You are redirected to Twitter, (login if isn't), click allow access, get redirection back to your callback URL.
PIN mode. You get a link to open, (login if isn't), click allow access, receive PIN code. Use this PIN code to authenticate your app.
Do I understand correctly that PIN codes also expire? How is it possible, given a username and password just to tweet from a client application? How can a server side script log in with the username/password and click allow access? All scenarios I could google up are for a web application to authenticate via twitter where the user is in front of the browser to walk through the redirect.
All scenarios I could google up are for a web application to authenticate via twitter where the user is in front of the browser to walk through the redirect.
The user has to be there to authorise you the first time (just as they'd have to provide you a username and password), but the resulting access token does not expire and can be reused (unless the user deauthorises your application, that is).
Store the access token - it's as good as a username/password. Better, actually - if they change their password, your access remains.
The PIN does expire under OAuth 1.0a. Using the verification code returned requires use of the temporary request token in the initial authorization request.
OAuth 2.0 defines more flows - one of which uses a direct login/password mechanism. It's up to Twitter to determine which flows they decide to implement. You can also embed a user-agent in the app.
Desktop apps suffered from a really bad user-experience with OAuth 1.0 which led to 2.0. It's doable, but painful. You can request XAuth access if you need to from Twitter as well. It's almost the same as basic auth.