I'm currently having massive trouble with Vimeo's Oauth implementation and my desktop app. My program does the following correctly.
1- Requests a Unauthorized Request Token with my key and secret and returns - a Token and a Token secret.
2- Generates a URL for the user to go to using the token which then shows our application's name and allows the user to Authorize us to use his/her account. It then shows a verifier which the user returns and puts into our app.
The problem is the third step and actually exchanging the tokens for the access tokens. Basically every time we try and get them we get a "Invalid / expired token - The oauth_token passed was either not valid or has expired"
I looked at the documentation and there's supposed to be a callback to a server when deployed like that which gives the user an "authorized token" but as im developing a desktop app we can't do this. So I assume the token retrieved in 1 is valid for this step. (actually it seems it is: http://vimeo.com/forums/topic:22605)
So I'm wondering now am I missing something here on my actual vimeo application account now? is it treating it as a web hosted app with callbacks? all the elements are there for this to work and I've used this same component to create a twitter Oauth login in exactly the same way and it was fine.
Thanks in advance,
Barry
Fixed. It was a problem on Vimeo's end.
Related
I want to revoke the session of a user logged in to my app with google authentication.
I retrieved the informations for this user available on this image. Among them we find his token, useful for the revoke.
According to the documentation provided by Google there is a REST call to answer my problem.
https://developers.google.com/identity/protocols/oauth2/web-server#tokenrevoke
However I get this error every time :
The requested URL /revoke?token=eyJhbGciOiJSUzI1NiIsImt..........
was not found on this server. That’s all we know.
Maybe the token which is not valid but I don't understand why in this case.
I think we need to start with being clear as to what it is you are trying to do.
If you are trying to log the user out of their google account the anwser is you cant. Google does not allow third party apps to log users out of their accoutns.
If you are trying to log the user just out of your app itself. Then assuming you have a web app just delete the session or the cookie depending upon how your system is running.
If it is an installed app again just delete the stored tokens which you either have stored in a var you are passing around or in your database.
If you want to completely have the users consent to your using their Google data removed then you would use the revoke command. Revoke world require that you send a valid access token. This will remove all consent that the user has granted your application to access their data. Revoke is not preformed on an Id token.
However by looking at your image I can see that you have an id token, which implies to me that you are using Google signin which is not Oauth2. Revoke is intended for use with Oauth2. Try sending the one that say authToken that might work. If not I think you should just remove the session cookies.
POST request works, GET request return the known error
Goal
Fetch a company's updates save them locally in a background task
Problem
This should be done as a backend service without any real user interaction. We could provide a user account to use, but the authentication is a problem: There is literally no one to answer the OAuth redirect and there is no public redirect URL to configure, since it's a background service.
Is there any way to access the API without having a redirect URL or a real user?
You can get an initial access token in a regular front end flow, for you as the app developer i.e yourself as the LinkedIn user. Once you've got that, you can store it in the backend and use it for 60 days to get access to the LinkedIn APIs.
After 60 days you need to refresh the token as documented in:
https://developer.linkedin.com/documents/handling-errors-invalid-tokens
Unfortunately LinkedIn does not (yet) support an autonomous refresh flow where your app can get a new access token by presenting a refresh token on a backchannel. So the developer will have to refresh the access token by a manual login every 2 months.
Well, it is still all HTTP and HTML, so in fact there is no real reason to show the OAuth dialog to a user, as long you can strip out the necessary parts in the HTML authentication dialog and send a valid response back to the server, using the username and password from the user (which you can obtain from him, or save it yourself in a config file if it is you).
Note that there might be a legal issue if LinkedIn demands you to actually show the dialog, beside that, there is no technical need.
PS: I'm working with OWIN + OAUTH + YAHOO OWIN
I've been working with Yahoo OAUTH API these days and facing a weird situation:
My web app asks authorization to the user. The user accepts and give asked permissions. Then, let's suppose, he closes the browser and at another time, he opens it in my web site again. I call Yahoo OAUTH API again but, instead of automatically understand that the user already gave me the permission and redirect to my page, Yahoo shows the "User Authorization Page" again. The code is the same and so is my request.
Do you guys know why and what should I do to avoid that annoying behaviour?
By the way, I'm working with Google, LinkedIn and Facebook the exatctely same way and all is fine.
Thank you in advance.
For others facing the same problem with YAHOO:
Once you first get the access token, you need to store the oauth_token, oauth_session_handle and the access token secret (not the request token secret).
Let's call "oauth_token" as "Access Token Id".
Then, everytime user accesses your page, you pass them to the api:
oauth_token: contains the stored Access Token Id.
oauth_session_handle: contains the stored session handle
oauth_signature: is the consumer secret concatenated with "&" and access token secret
oauth_signature_method: plaintext
In my case, I used the GET method.
See more at https://developer.yahoo.com/oauth/guide/oauth-refreshaccesstoken.html
In case of any doubts, just send me a message and I'll be glad to help.
Trying to test installation process for my marketplace application. Google documentation says that I can test installation process by using Test Install Flow button in the console. When I click on that button, I see the authorization dialog and I click accept. The dialog is closed and app is installed on the domain I am testing.
Question: Should I be getting and storing a refresh_token at some point in this installation process?
There is an Install URL that I can specify in Drive SDK but I can't find documentation about when Google posts to this install URL and what gets posted.
Here is a project which shows you how to do just that:
Checkout the section called: Cached Credentials
http://www.codeproject.com/Articles/488185/Working-with-Google-Drive-in-WPF
Excerpt from the above URL:
Provided the user allows access, the authorization server will return the authorization code. It can be sent back either by the Google server calling a web service endpoint opened by your application or in the title of the page sent back to the browser. Because of the challenges of spooling up a web server, opening a connection through any possible firewall(s), etc... it is much easier for installed applications to simply scrape the authorization code from the title of the resulting web page. That is the technique used in the sample project. If successful, the title will be set to Success code=xxxxxxxxx where the xxxx's are replaced by a unique authorization code.
The authorization code only gets you invited to the party. You can't do anything with that code as far as API access. The Authorization Code must be exchanged for a short-lived access code and a long-term refresh code. In the Google.Apis.Authentication.OAuth2 library is a class called NativeApplicationClient. This is the wrapper for the authorization server and it has a method called 'ProcessUserAuthorization'. This method takes the authorization code we retrieved after the user authorized the application's access and turns it into the access token and the refresh token. The access token is what we actually need for the task at hand and it is maintained in the NativeApplicationClient. It gets passed with all subsequent API calls. The nice thing about the NativeApplicationClient is that it knows how to verify the access token and how old the token is. If the token has expired, the client will use the refresh token to get a new access token. That takes the burden off of us to manage token lifetimes.
The short answer to your question around the refresh_token is - No. You won't get a refresh token upon install. You have to instead ask for a fresh access_token using a Service Account key you've got.
So basically, the way a Google Apps Marketplace (GAM) app is supposed to work is to get itself a Service Account and build with that for all authorization. There are no refresh_token with Service Accounts, just fresh new access_token. For an app that is installed by consumers you should use standard web server flow. This is one area of complexity that wants to be both a consumer and enterprise app.
When an admin installs your app, he/she is in essence authorizing your app's Service Account key to his/her domain.
Once an app is installed, that Service Account has full delegated access
Regarding the Install URL for a Drive app. You can ignore that for a GAM app.
Hope this helps. We'll release some end to end sample at some point soon .
I am trying to do a Twitter connection using a webview in the excellent Appcelerator Titanium. I know there is a great library from David R out, but I do not want to use a popup and I feel that I need more control over the flow.
My question is: During the authentication flow I need to get an oauth_token which (in my knowledge) is a combination of the consumer key and other values. How can I do this? How can I generate this token so that I can continue the process?
I am of course using Javascript.
Thankful for all input!
It is a multi-step process based on the OAuth 1.0 specs, you can find the details at <http://oauth.net/core/1.0/>
Before doing anything, you will need to register an application with Twitter and they will provide you with a Twitter API Key and a Consumer Token (Key and Secret).
For the next steps, I highly recommend you use OAuthConsumer or some other library, but the steps include generating a proper request to get a "Request Token" from <https://api.twitter.com/oauth/request_token>
then using this Request Token, you need to request the user to authorize your application using <https://api.twitter.com/oauth/authorize?oauth_token=REQUESTTOKENKEY>.
This last step provided you with a Request Verifier allowing your application to make the final request for a permanent Access Token from <https://api.twitter.com/oauth/access_token>.
When you receive the Access Token, you should store a copy somewhere so the user does not have to re-authenticate your application every time (unless that's what you desire). This Access Token does not expire until the user specifically removes the access rights of your application from his Twitter profile. Make sure to store the entire Access Token, meaning storing both the Key and the Secret.
Good luck!