In LinkedIn API, the access tokens will be expired after 60 days, I want to refresh them in 60 days before they are expired in a console application. I viewed this document: https://developer.linkedin.com/blog/tips-and-tricks-refreshing-access-token, and I also viewed many posts in this forum, but it looks like the refresh flow is still now clear for me.
Please note that:
I need to refresh access tokens from a console application - it is not a website, it is a tool running in backend, it has no cookies and cannot open web page to ask user to login.
And if there are some sample code (not for website) that should be better, for example: C# or Java code.
You can use curl to accomplish this. For whatever programming language you use, there should be a relevant curl library.
The way this works is as follows:
You send a POST request to https://api.linkedin.com/uas/oauth/requestToken
You receive back a request token. Use that token in place of XXX in the following call: https//www.linkedin.com/uas/oauth/authenticate?oauth_token=XXX
You will receive the response you need, which includes the access token, which you need to save. It will not expire for the next 60 days.
If you could elaborate on the issues you're having, that would certainly help.
I see what you mean now. Linkedin doesn't allow you and will never allow you to do this. The reason access tokens expire is in order to add an extra layer of privacy protection for users. Linkedin would never want you to access user data if the user's aren't actively using your application. Of course, you might have a situation where no action is required on their part, that's the only drawback. Therefore, you would need to give them a reason to visit your application at least once in each token's lifetime.
I hope this helps.
Related
I am using Google Analytics API to fetch analytics data. I tried to authenticate it using following steps:
Created OAuth client ID in https://console.developers.google.com/ credentials section.
In consent screen I had set publishing status as testing
In OAuth 2.0 Playground I got the refresh token using above generated client id and client secret
Then I am using it to generate access token through it.
But after a few days, the refresh token expires although it is mentioned that the refresh token's validity is life long.
If your app is in testing mode then user tokens will expire in 7 days. Please find this explanations here: https://support.google.com/cloud/answer/10311615#zippy=%2Ctesting
I needed to send mails from a gmail account that I have access to, using nodemailer. It works for a couple of days before my refresh token is mysteriously revoked, even though the account belongs to me. A google search brought me here and I had been watching for a while hoping someone would help with a solution.
As you mentioned, this seems to happen with only test/unverified apps and I'm guessing google revokes tokens for such applications in your account after a few days. After much trials and errors, here is what I did.
NOTE: This is solution is only applicable to accounts you own, otherwise you must verify your app to access other people's accounts
Generate a new refresh token (existing one is most likely revoked) as described in this SO post
Go to the security tab of your google account dashboard
Under the Recent security activity section, you should see a security alert for your app.
Click on the context menu next to the notification and click DISMISS
At this point you'll be presented with a dialog of options where you indicate the level of trust you have for the app. I just went ahead and said I trusted the developer/app, obviously. And that's it! The refresh token should persist after this.
I could not find anything related anywhere else.
The other answer pointed me in the right direction but for me the option was located somewhere else: security > security checkup/security issues found > context menu next to your app > dismiss
This issue seems to be for unverified apps, Simply delete the token file from your project and rerun the project, it will create a new token.
My problem was when I've added access_token instead of refresh_token.
What I did:
Go to https://console.cloud.google.com/apis/credentials/consent and change from the testing status to published.
Delete the current token file.
Authorize the API again by signing into your gmail account. You will be sent to a warning screen. From there, you can choose to proceed.
When done you'll get a new token file
The solution is to delete your token.json file to force Google to find a new token.
I was able to get it to work WITHOUT a verified app. Perhaps the refresh() method will work once my app is verified. Not sure on that one.
Given a backend wrote in nodejs that returns a page that should either link to login (if the user is not logged in) or a link to logout (if the users is already logged in).
Considering I'm using firebase as authentication tool, how can I know in the first request, when the user is accessing the website, if is he authenticated to then
set the ejs template to respond with the correct link ?
Is there some header, or token that can I use ?
The only solution I found was use ajax after the server response, but I don't like this solution because apparently there is a delay in the link renderization.
As far as I know there is no way to know if the user is authentication on the initial request. From a quick inspection no data is sent along with that request. That kinda makes sense, given that upon this request it is not even known if you're using authentication to being with.
Update
I actually just ran into this blog post from one of the Firebase engineers, which seems promising: Introducing session cookies for server-side web apps. I haven't fully read it yet, but the title sounds like it may be exactly what you want.
In Webserver Grant Flow
After I obtain the Authorization Code from the authorization authority (after the user has authorized my access) how long is that code usually valid form?
The reason i am asking is, can my webserver store that code and use it in later sessions to retrieve a new access token without the need for the user to re-authenticate again? Should that be the flow?
FYI my goal is make requests from Adobe Analytics and Google Analytics on behalf of my customer. So i would want to ask my customer for authorization once until he revokes my access.
Speaking strictly of Google Oauth. There are three types of codes or tokens you should be aware of.
Authorization code
Access token
Refresh token
Authorization code is return when the user clicks accept to your application accessing their data. This code is used to exchange for an access token and a refresh token. This code can only be used once and is extremely short lived 10 minutes I believe.
Access tokens are used to access private user data. They are valid for approximately one hour.
Refresh tokens are used to gain a new access token when the access token has expired. For the most part refresh tokens do not expire however if it has not been used for six months it will no longer be valid and of course the user can always remove your access.
Answer: No storing the authentication code would be pointless. You will need to store the refresh token. make sure you are requesting offline access of your users.
I cant help you with adobe analytics however I suspect it is similar this is standard Oauth protocol we are talking about.
This may seem like a totally idiotic question but I am looking at writing a web app/service that will utilize google's calendar API's and I needed to see if I have the ability to write to a users calendar when the user isn't logged into there google account. I couldn't find any clear documentation that illustrated whether or not I could do this or not. I pictured the authorization process something the user agrees to when they sign up for my site and then my app can go add things to there google calendar. Does anyone know if this is possible? If so, can someone hook me up with a link that illustrates how that works?
Thanks in advance
You're thinking about "logged in" wrong.
Because web connections don't persist between requests, any web-site or web-service is checking headers such as the Authorization header and/or Cookie header (depending on what authorisation method is used), with each and every request and matching the request to a user.
Hence logging in* means that the web client (browser or whatever) is set to use the details that relate to a particular user in making the request.
When you use the API, the authorisation information you send, is performing the same job. As such, when the user is using your API they are logged in through your API, whether they're logged in through a web page or other application or not.
E.g.:
My web browser is currently logged into google to an account I use for work stuff.
My mail client is logged into google calendar to an account I use for private stuff.
When I look at google calendar, I see that I don't have any calendars (I don't use it on my work account).
When I look at Thunderbird, I see my calendars.
If I peek at the traffic being sent by the browser and mail client, on both I see headers like:
Authorization: GoogleLogin auth=...stuff I'm not going to share or it would help you impersonate me
So, I'm "logged in" on Thunderbird because the code using the API logs me in itself.
Indeed, the same application can access multiple accounts and be "logged in" to all of them, as long as it has the authentication details to do so.
*Strictly, some would argue that "logged in" isn't the correct term at all, and refers to different sorts of access mechanism where there is state on the connection. Whatever about that opinion, we use the metaphor of being or not being logged in, because users understand it.
The answer to your question is yes. Use OAuth 2 and the Authorization Code flow (web server flow), with offline enabled. Store the refresh tokens (which last indefinitely until the user has revoked), and you'll be able to upload events to Google Calendar even when the user isn't currently logged in.
More info: https://developers.google.com/accounts/docs/OAuth2WebServer#offline
Credits to Ryan Boyd for this note.
I want to build a custom asp.net control to put on a webpage that will allow people to see a piece of information from my facebook account that requires auth. For the sake of simplicity let's just say I'd like it to display the last thing that I liked. I don't want the visitor to my site to have to be logged into facebook (nor would they have to be my friend on fb). I want my site to somehow store a token that I have authorized and then it will use this token for the access. I know this can be done initially, but I'm confused what happens when the token expires. Or for that matter if I log out from facebook. Is there some type of token or secret or something that I can request that can be auto-renewed again and again by my website independent of any login state that I have as an fb user? Does this require me creating an fb app and associating the token to it?
I don't have any code at this point, I'm looking for a higher level of guidance on the protocol that should be used here, from there I can hopefully figure out the code from existing samples, docs, etc. This is my first code interaction with facebook so don't assume that I know very much at this point :-)
EDIT: I've been reading everything I can about this topic and I can't seem to find a solution. In the past there was an RSS feed but that appears to be gone now. Then there was also the offline_access permission which is no longer available. This seems like such a simple task but I'm just not able to connect the dots. I have been able to get the initial user token with perms for reading "likes", that's easy. Now I can store that in my website's db and use it to make requests for that data anytime someone loads my page. But eventually the token will expire and I'm not seeing any automatic way to renew it that wouldn't potentially involve user "Larry", who happens to be browsing my website, being asked to supply MY facebook credentials. Basically it seems as though I could never log out from facebook or I'd be risking a broken feed on my website. Is the fb auth model just not set up to allow for thist? To summarize again - a user Bob wants to give his permission to acme.com to always be able to display Bob's most recent like regardless of whether Bob is logged in to fb or not. He would only want to have this stop working if he revoked authorization to the WhatDoesBobLike app which runs on acme.com. Possible?
-JT
You would need an extended access token. It will only last up to 60 days and from then you would need to re-extend.
If it were a page you could extend the user access token then grab the page access token which would never expire.
Read more at
http://developers.facebook.com/roadmap/offline-access-removal/