I am working for a course work that needs to console the new release albums, and I try to get OAuth Token in the API console, However it can only run short time, after half hour it does work.
How to gain a long term OAuth Token for it ?
The access tokens issued by the Spotify Web API have an expiration time of 1 hour. If you implement the Authorization Code flow you will get an additional refresh_token that you can use to obtain a new access token when the current one expires.
I recommend you to read the Spotify Web API Authorization Guide to get an overview of the OAuth 2.0 authorization framework, and also the beginner's tutorial that shows how to implement the authorization code flow step by step.
Related
I'm building a website that integrates Instagram Basic API to show my media posts. So far, I managed to authorize via
https://api.instagram.com/oauth/authorize?client_id=X&redirect_uri=X&scope=user_profile,user_media&response_type=code,
fetch a short-lived access token via https://api.instagram.com/oauth/access_token?client_id=X&client_secret=X&grant_type=X&redirect_uri=X&code=AUTH_CODE_RECEIEVED,
fetch a long-lived access token (as per the response I receive) via https://graph.instagram.com/access_token?grant_type=ig_exchange_token&client_secret=X&access_token=SHORT_TOKEN_RECEIEVED,
and lastly, show my media posts via https://graph.instagram.com/me/media?fields=id,caption,media_type,media_url&access_token=LONG_TOKEN_RECEIEVED.
However, the problem I am currently facing is that the obtained long-lived access token - which is meant to be valid for 60 days? - is expiring per hour or so. Meaning, on client-side, when I'm requesting the server to fetch media posts, using the token, the response returns with expired token exception.
I tried to use FB Access Token Debug Tool to check the token validity, and it shows that the token does indeed expire in about an hour. Why is this happening? I checked the response I'm getting from the long-lived token API, and it's a success with the token, grant_type, and expires_in fields.
Below is the screenshot of the debugger result.
.
What I'm trying to accomplish is rather straight-forward. Generate a long-lived access token that "should" be valid for 60-days use on server side. Then, I'll have to automate the token-refresh process afterwards. Any suggestions to the above issue?
Thanks in advance.
Regards,
Moh. Bokhari
The difficult part is getting a short-lived access token first; I found this useful page which explains step-by-step with screenshots on how to get a short-lived access token.
The link to the website
On my localhost, I have authenticated my user and goten a Refresh Token and Access Token using Passportjs.
I am using Google's Official Node.js library to get the Google Analytics data and it all seems to work fine.
On this GitHub issue, Justin clearly mentions that the expiry is set by Google's APIs.
How long is the refresh_token valid and at what time do i have to authorize myself again?
This is more of an Oauth2 question then a Google Analytics question.
Access tokens on google servers are good for one hour.
The refresh token does not expire and you can use it as many times as you want to request a new access token.
You should still handle invalid refresh tokens in your code. The user can revoke your access via there Google account. You can have max 50 out standing refresh tokens before the first one starts working. If i authenticate your application you will be given a refresh token if i do it again you get another refresh token there can be max 50 of them outstanding.
If the refresh token does become invalid you should just request authentication from your user again. The library you are using should be handling refreshing the access token for you.
I'm creating a node.js application that will update playlists (owned by an account in which I have credentials) daily. According to the Spotify documentation, to add tracks to a playlist (https://developer.spotify.com/web-api/add-tracks-to-playlist/), authorization must be supplied using oauth2.
I'm struggling to find a way to do this completely server side with no redirects/etc. It seems like if I can get a refresh token, I can just use that?
I've been looking at the spotify web api node module (https://github.com/thelinmichael/spotify-web-api-node), oauth.io, and the spotify api.
Any ideas would be appreciated! There is only one account that will have to be authenticated, so it could be hard-coded at least for now.
You've picked the correct authorization flow - Authorization Code, since you need an access token that's connected to the user who owns the playlists you're updating. This of course also gives you the ability to refresh the token whenever you need to. (The expiration time is one hour, but you don't need to refresh the access token until your application actually needs to use it.)
As a sidenote, the Client Credentials flow is meant for server to server communication that doesn't require a user's permission, e.g. to search, read a playlist, or retrieve new releases. The Implicit Grant flow is meant to be used in frontends, and doesn't allow you to refresh the token.
I'm struggling to find a way to do this completely server side with no redirects/etc. It seems like if I can get a refresh token, I can just use that?
Once you have the refresh token you can continue to use it to retrieve new access tokens, which can be done without any user interaction. You need to do some preparation work to retrieve the refresh token though.
Following the steps describing the Authorization Code flow, you first need to direct the playlist's owner to a URL on Spotify's account server.
The documentation contains the following example URL:
GET https://accounts.spotify.com/authorize/?client_id=5fe01282e44241328a84e7c5cc169165&response_type=code&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback&scope=user-read-private%20user-read-email&state=34fFs29kd09
Simply replace the client_id and redirect_uri with your application's information. Also modify the scope parameter to match the scopes you need, which from my understanding of your use case is playlist-read-private,playlist-modify-private,playlist-read-collaborative since you want to be able to read and modify all of the user's playlists. Supplying state is not required.
Using spotify-web-api-node you can generate this URL using the createAuthorizeURL method, but since you're only doing this once it's unnecessary to write code for it.
Instead, simply open the URL in your browser.
If done successfully, you'll be taken through a little login dance where your application asks for your permission to read and modify your playlists. When this is completed, Spotify's account service will redirect the browser to your redirect_uri URL with a code query parameter included as described in step 3 in the Authorization Guide.
However, since you're only doing this once, it would be enough to start a webserver on your own machine, set your application's redirect_uri to your localhost, and complete the login flow. Have a look at web-api-auth-examples for a ready-made node.js application that fires up an express server and reads the authorization code.
Once you've got the code, you can trade it for an access token using cURL as it's done in step #4 in the Authorization Guide, or use the code in the web-api-auth-examples repository.
Finally, with the tokens retrieved (step #5), you can start to use the Web API with the access token, and get a new one when it expires using the request in step #7.
spotify-web-api-node has a helper method to refresh the token. Search the main documentation for the refreshAccessToken method.
This use case is slightly mentioned in the FAQ section of the Authorization Guide.
As you said, you need to obtain a refresh token using the authorization code flow. For that you will need to carry out the OAuth process using your user account, the client_id of the app you have registered, and the scopes you need (it will vary depending on whether the playlist is private or public). Then, take the refresh token you have obtained and the client secret key of your app, and you can obtain access tokens without the need of the login form.
This related StackOverflow question might help too Spotify automated playlist management with PHP back-end and rate limits
I setup a new key for Public API access for a server application under my the APIs & auth > Credentials screen on the Google Developers Console.
Doing a YouTube data api request just stopped working and as a last ditch effort I regenerated the key. Now I'm seeing that the status row now states that it will be active until 1 day in the future. Why? I want this key to be active forever.
Is this Google's way of forcing me to use oAuth on a server app?
When using OAuth 2.0 you'll go through the OAuth flow and end up with an Access token and a Refresh token.
The Access token is short-lived and will expire relatively quickly. The Refresh token is long-lived and might expire in a year, or maybe never.
You can Refresh your Access token and use the new token that you receive:
Check here for documentation
I am trying to use gmail smtp using oauth 2.0. I have used aspose.dll for requesting access token using authorization url. I do not get refresh token when i get the response.so there is no way to request new access token if previous is expired. So i thought of getting access token every-time my app requires . And if authorization code gets expired then i can not follow this approach.
does authorization code for gmail oauth2 ever expires??
Google's OAuth 2.0 does provide Refresh Tokens!!! This link here explains the various flows and talks about apps obtaining both access and an optional refresh token for all scenarios.
Authorization code DOES expire! That's what OAuth protocol dictates. I cannot find an exact time period to quote here for Google, but I do know that for Facebook), the authorization code expires in 10 minutes (See the december 5 change in the link.). The Refresh Token has been made available for use cases like yours. If the authorization code were to persist, what difference would remain between a Refresh token and Authorization code.
I'd suggest you look up the documentation of the Aspose libraries you are using.
PS - Authorization code/access tokens/refresh tokens are all issued by a central Google Authorization server! So, we're talking about Google's Authorization code which, as I said, does expire.
Good luck!
EDIT - Adding more info for you
The authorization code generated by the
authorization server. The authorization code MUST expire
shortly after it is issued to mitigate the risk of leaks. A
maximum authorization code lifetime of 10 minutes is
RECOMMENDED. The client MUST NOT use the authorization code
more than once. If an authorization code is used more than
once, the authorization server MUST deny the request and SHOULD
revoke (when possible) all tokens previously issued based on
that authorization code. The authorization code is bound to
the client identifier and redirection URI.
Source - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-31
Section - 4.1.2