I'm making a personal smart mirror and i'm looking to integrate the spotify API to display my 'currently playing' track. However, I've noticed that in the authorization process, you need to physically click log in and authorize the app in order to get the credentials required to move forward in obtaining your data. Could this be automated/require no user interaction?
I am referring to step 1 of the api authorization guide.
Many thanks.
If you are using this for a personal smart mirror you shouldn't have a problem. You only need to authorize by clicking a button in a browser one time and will be able to make all API calls afterward without needing to click anything.
Specifically, after you do in step 3 of the authorization flow you will be given a refresh token. After the authorization token expires you can use the refresh token to refresh the authorization automatically without clicking anything.
From their documentation:
Accessing your data without showing a login form
I want to interact with the web API and show some data on my website. I see that the endpoints I need authorization, but I don’t need/want a login window to pop-up, because I want to grant my own app access to my own playlists once. Is there any way of doing this?
You basically need an access token and a refresh token issued for your
user account. For obtaining a pair of access token / refresh token you
need to follow the Authorization Code Flow (if you need a certain
scope to be approved) or Client Credentials (if you just need to sign
your request, like when fetching a certain playlist). Once you obtain
them, you can use your access token and refresh it when it expires
without having to show any login form.
If its not for you personally you could jump through hoops and write code that fakes being a web browser, perhaps using something like curl or selenium but odds are it is against their terms of service and are if you get caught they'll ban you.
Related
I'm building a website using ruby on rails which is hosted separately which makes requests to another backend api rails app which is again hosted separately. Obviously i've setup the backend api with token based oauth authentication.
Now since im not dealing with sessions, and it being stateless n all, How can I stop users from accessing certain view pages in my front end web app? For example, I have a consumer/booking page. I don't want the user to access this page without being logged in. But anyone can just enter the url and open any page they want right now.
On user login (ajax call from .js.erb files), im getting the token and storing it in localStorage variable for every future request to the api. I know I should use this token somehow to stop users from access restricted pages. But I just dont know how.
Now as you have stored the token in the localStorage, you will need to pass this token with the request to the page where you want to restrict access and check if the user is authorized to access the page or not.
TL;DR: there is no standard method or library for this; you must implement such functionality as you see fit.
I'm assuming you're using some sort of front end framework like react; if so, then any request to change the current view should be terminated if there is no valid token in localStorage. Check out this post regarding conditional rendering in React; if you're using something else, the methodology is still pretty much the same.
Otherwise, I would build a small script to include in the beginning of every page that checks whether or not there is a valid token and if there isn't, calls window.history.back() to return the user to the previous page.
(Another way of doing it is to intercept every call to a static HTML file on the server, check if there's a token, and send the file if there is. Otherwise, you can send a custom error page or whatever).
I have used the Youtube-api and also created the oauth-clientId for some demo project. I also used the Client libraries (java & javascript) for uploading videos to my channel and i succeeded. But i don't want to share my login credentials and want my client users to upload videos to my channel. Is there any way, i mean documentation or procedure or youtube-implementations?
Assuming that you are using Java as you said. You should have a refresh token after your application has been authenticated.
The refresh token can be used to request a new access token. You should use this refresh token to allow others to upload to your channel. Note: To my knowledge you cant get a refresh token with the JavaScript client library due to security issues. You need to use a server sided language to do this.
For Refrence:
YouTube does not support service accounts so that wont work. API Key is only used for accessing public data so that wont work either.
I finally found an answer to my question and now my users[whom i give some authorizations] can directly upload to my youtube channel.
As per the comments i received for my question, i came to the conclusion that i have to do it at the server side because of the security issues.
The thing which came to rescue is namely Refresh Token.
I first created a simple application through which i logged & uploaded video [uploading is not necessary] into my youtube account and received the respected refresh token
Then i saved that refresh token through which i created a Credential object manually.
You can check the code provided by google :
UploadVideo.java
Credential credential = Auth.authorize(scopes, "uploadvideo");
This is what i replaced with this and obtained my own refresh token.Refresh token does not expire like normal access token, and is used to generate normal access token when needed. So, refresh token was the key to my question
Then at the backend, the only thing you have to do is just create the Credential manually. You can use this code
getCredential = new GoogleCredential.Builder()
.setJsonFactory(JSON_FACTORY)
.setTransport(HTTP_TRANSPORT)
.setClientSecrets(clientId, clientSecret)
.build()
.setRefreshToken(refreshToken)
// The refresh token here will be the same you received offline.
Here is the official google doc about this concept
Refreshing an access token (offline access)
Access tokens periodically expire. You can refresh an access token without prompting the user for permission (including when the user is not present) if you requested offline access to the scopes associated with the token.
If you use a Google API Client Library, the client object refreshes the access token as needed as long as you configure that object for offline access.
If you are not using a client library, you need to set the access_type HTTP query parameter to offline when redirecting the user to Google's OAuth 2.0 server. In that case, Google's authorization server returns a refresh token when you exchange an authorization code for an access token. Then, if the access token expires (or at any other time), you can use a refresh token to obtain a new access token.
Requesting offline access is a requirement for any application that needs to access a Google API when the user is not present. For example, an app that performs backup services or executes actions at predetermined times needs to be able to refresh its access token when the user is not present. The default style of access is called online.
Server-side web applications, installed applications, and devices all obtain refresh tokens during the authorization process. Refresh tokens are not typically used in client-side (JavaScript) web applications.
Goal: A single page application that uses Facebook authentication to login, but does nothing with Facebook after that.
Tech: Facebook Javascript SDK, AngularJS, angular-ui, .Net Web Api
I'm creating a Single Page Application (SPA) in Javascript using AngularJS. I'm using the Facebook SDK which is working to authenticate the user; it returns me a facebook user id, an access token, token expiry time, a signed request, and some other stuff, all on the client side. I then pass this information to my service, mostly because I feel I should. After this I don't really care about Facebook. But I want to make calls to the server to load the user's data.
I could just make all requests using the facebook user id, but there would be no security because any client could just call that endpoint and pass any user id until they found a valid one.
I could use the access token on each request as well, but I still think this is a security failure; when the user first logs in and I pass it to the server, well that endpoint could also be called by any client... "LoginServer('myfakeaccesstoken', $knownUserId)
I get the feeling that I should validate the token on the server side back with facebook, and then I can safely rely on teh token on future API calls, but I'm wondering if there are any other approaches?
The Facebook documentation seems to focus too much on me wanting to make follow up calls to their graph API when I really don't care after my user is authenticated.
I am trying to wrap my head around the G+ Sign-in flow, but I am not sure if I have gotten it right.
I have mainly been looking at this page
Where in that flow can I connect to my own database and fetch things such as username and permissions, and what am I supposed to store as identifier in my database (to quickly identify them next logon)? Should I talk to the G+ API and get their G+ ID and then store that (together with the data I want to store about the user)?
How would the flow look the second time they sign-on?
I need something that will in the end give me the G+ ID (if I used that) so that I can find them in my DB.
The quickest way to get going with Google+ API calls is the Google+ Quickstarts. These samples will get you going with code that should be ready to copy and paste into your applications. I'll shortly discuss the flows demonstrated in the apps.
As with OAuth 2.0, the goal is to get a bearer token (access token in OAuth 2.0) to authorize API calls. The token can be retrieved a number of ways, but the most important for sign-in using the Google+ Sign-In button is code exchange.
The first time a user encounters your site (let's call it sign-up) the flow will be code exchange. The code exchange pattern is:
User reaches your site
User clicks preferred authorization (Google+ Sign-In)
User is presented with consent / authorization screen
Code is returned from JavaScript to the web client
The Web client (HTML/JavaScript) passes the authorization code to your server
The server exchanges the code for a refresh and access token then caches these tokens
At this point, your server has an access token. This means that you can make API calls (e.g. plus.people.get('me'), which gets the signed-in user's profile) to Google based on the user permissions granted to your app.
The user should now be authorized with your server and authentication should happen based on the user's session and so forth. However, now you have a new problem, what happens when the user accesses your site again from a new browser, or otherwise destroys their session?
This is a great time to transition to the next important flow: the authentication (let's just call it "sign-in") flow. For sign-in, you should have the client pass your server an authentication credential (again a bearer token) and then verify the credential before establishing a new session for the user in your database.
The verify token examples on the Google+ Github page demonstrate concise code for sending and verifying ID tokens.
Let's discuss the details of one approach to passing a type of bearer token, the ID token, for authentication.
User signs in to your site
The Google+ Sign-In button returns an ID token in a callback
The client securely passes the ID token to the server
The server verifies the ID token*
The client session is then authenticated
The steps for * are best put in another question, however a typical set of tests includes:
Verify the token's certificate is Google's
Verify the client id is for this app
Verify the user has an account on your site (optional, do this if you need offline access)
Verify the token hasn't expired
Hope that clears things up for the two.
There is one final flow you should be aware of, used for offline API access, token refresh. Token refresh happens when you have a refresh token and an expired access token. For Google's implementation of OAuth 2.0, access tokens expire after 3600 seconds (1 hour). Because these tokens expire, you need to be able to get new access tokens when your stored access tokens expire. To do this, you pass three bits to Google:
Refresh token (retrieved from code exchange)
Client ID (retrieved from the Google developer console)
Client secret (again, retrieved from the Google developer console)
These parts are passed to the Google OAuth server and the server will then return a fresh access token that you can use for offline API access.
There's a wealth of information on this topic, see also:
Using the one-time code flow for Google+ Sign-In
Google+ Developer documentation, Token Verification
I've created a custom open graph action that uses the publish_actions permission.
Once the user has granted this permission, which access token do I need to use to post the open graph action? Can I just use my app token or do I need to use an active user token?
I've tested this and it looks like as long as the user has granted the app the permissions, using just the app token works. I'm worried though that this might be a quirk in the api or that it might change since its not in the api docs.
Let me know how others have implemented something similar, and if it helps this open graph action has not been submitted for approval yet.
Both will work, and in some cases the app access token is needed (this is an option you can specify on specific action types), but in general you should probably use the user access token, as you'll need this to read back the data and make any other api calls on the user's behalf