How can I implement YouTube Resumable Uploads for myself without Oauth - youtube-api

I am looking at the documentation on Resumable Uploads, and I noticed that I need to use OAuth for creating an application for other people.
However, I would like to use this protocol for myself, and see what I can do with it. Is there any demo Oauth that I can do, or another way to authenticate (but for my personal self?)

For browser-side scripting, there's Google’s Client Library for Browser-side JavaScript, GAPI. See the official document Javascript Quickstart for the initial steps you have to be going through.
Then look into the resumable upload implementation provided by Google:
upload_video.js, and
cors_upload.js.
Once again, your app has to implement one one way or another an OAuth 2.0 authentication/authorization flow, if you'll not make use of GAPI. (See this doc too.)
The official document w.r.t. the kind of authentication/authorization required by your app is: OAuth 2.0 for Client-side Web Applications.

Related

Securing API using Oauth 2.0

I am creating new product. for that I have to use available security features. should I use Oauth2 or Json web token? which is better and in which situation these should be used?
I think you may find your answer in using org.apache.oltu.oauth2.
https://www.programcreek.com/java-api-examples/?api=org.apache.oltu.oauth2.client.request.OAuthClientRequest.AuthenticationRequestBuilder
You can see an implementation for oauth and openID here oauth server and resource server
Just to explain what they are,
oauth server creates the tokens
resource server uses that token and processes it to give you the requested data
You can also go through the following docs to understand what they mean and how to implement them,
sample implementation in java , oracle tutorial on the concept of tokens
If you want to do google API auth then you can go through this
I also found this stackoverflow link which is sort of similar question and has shared few of similar links. You should check that out as well.

Access Google Drive API v3 with Ruby on Rails

I would like to access my Google Drive account via their API inside of a Rails application. The idea is that I will store files, but I don't believe I need to implement any authorisation for it (like with Oauth2, for example), since I only want to access my account.
I have been researching for 2 days, but the Google documentation seems very confused and not very clear.
I started in vain with this guide https://developers.google.com/drive/api/v3/quickstart/ruby and tried to co-opt it for use inside of Rails, but since it relies on storing a token file returned upon authentication, I figured this wasn't really the right approach.
I don't have any code to share, just looking for some clarity on how I can achieve what I'm trying to do, or indeed if it's even possible.
Additional Info:
I'm using Devise for my own authentication, so implementing omniauth through that would be an option if it's necessary. I looked through some documentation around that which Devise has on their side, but I didn't want to go through that (it seemed like a lot) before knowing it was the correct course of action.
You need OAuth 2.0 to authorize requests on the Drive API as described on the documentation. In that link, you can find: «All requests to the Drive API must be authorized by an authenticated user».
To complete that authorization process, you should follow the instructions on the Drive API Ruby Quickstart linked on your question. Generating and saving a credentials.json for later use is the normal approach in this situation. Here you can read about using OAuth 2.0 over different scenarios.
I hope to have cleared your doubts on this topic, but feel free to ask further questions.

The authorization method of One Drive

I would like to know if One Drive supports those four ways of Authorization. Please refer to this link. https://www.rfc-editor.org/rfc/rfc6749#page-23
We are integrating our DVR and NVR with One Drive now and we need to understand which authorization method One Drive supports. We are trying to use OneDrive with embedded ARM processors, so the user does not have access to a browser as they would for a web-app.
Please kindly advise how we should proceed from here. Thanks for your time and I look forward to hearing from you.
Best Wishes,
Ted Yang
I am going to say yes, OneDrive probably supports those ways of authorization, because on their authentication documentations page they say the following:
The OneDrive API uses the standard OAuth 2.0 authentication scheme to authenticate users and generate access tokens.
That link takes us to the oauth.net site page for OAuth 2.0. On that page, we find the following:
The final version of the spec can be found at https://www.rfc-editor.org/rfc/rfc6749
which is the document you linked. The OneDrive API documentation says it supports OAuth 2.0, and your linking the definition of OAuth 2.0, so I think it's safe to say it's supported. How to use it is another question entirely, and one I am unable to answer.
I will note, however, that on the OAuth page, they have this to say about it's uses (emphasis mine):
OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.
I would presume that living room devices could include DVRs, and although your DVRs are for security purposes, the development of cloud storage APIs for either would undoubtedly be similar. So I would say this is probably quite possible.
How to do it:
First things first, you'll need to register your app. This gets you a client id and a client secret which you'll need. Registration directions
There are two methods: token flow and code flow. Token flow is two steps, and code flow is three steps. However token flow uses tokens that expire, so it would require the user to reenter thigns periodically. You therefor want to use code flow. Here's some directions for that.
Basically the steps of the code flow are:
Get an authorization code
User authorization code to get an access token
User access token to make API calls
You WILL need to make HTTP requests. I'm sure you should be able to do this with ARM embedded C. However, step 1 is what gives you to the Microsoft account login page. I am note sure how to circumvent this, exactly. I'm not sure you're supposed to be ABLE to circumvent this, since Microsoft doesn't want you handling their customers' passwords.
They have an example in Javascript that might give useful details on oauth in the oauth.js file. Javascript sample project

Grails: Securing REST API with OAuth2.0

I am building a REST API using Grails. I want it to be protected using OAuth2.0 client_credentials flow(grant_type). My use-case is as follows:
a external agent will send a request to something like
http://server-url/oauth/token?client_id=clientId&client_secret=clientSecret&grant_type=client_credentials
and obtain a access_token. Then, my URL(protected resource) should be accesible with something like
http://server-url/resource?access_token={access-token obtained before}
I am looking for something that makes doing this on Grails easy and quick. What will be the best way/tool/plugin to use for this ? Scribe library is an option, if there are any tutorials for my specific use-case, it will be great.
P.S.: I have tried the spring-security and related plugins, no joy there. Any alternatives would be nice.
I have the same issue. I found a lot of grails plugins that helped you authenticate your app against other oauth providers, but nothing that would help me make my app the oauth provider. After a lot of digging, I came across this grails plugin that will do exactly what you want.
https://github.com/adaptivecomputing/grails-spring-security-oauth2-provider
I'm still configuring it for my application, and I think the docs might need a few edits (specifically the authorization_code flow) but I got the simple client_credentials flow to work with minimal configuration. Hope that helps!
Based on my experiences, Scribe was built for OAuth 1.0 and has only very limited support for OAuth 2.0. In fact, for testing our own OAuth 2 implementation, all we could use from it was an HTTP request wrapper, we had to do anything else manually. Fortunately, doing it manually is suprisingly easy.
Since I still haven't found a fine open OAuth 2.0 library for Java (frankly I'm not familiar with Groovy), I encourage you to write the client code for yourself. You don't even need a client callback endpoint to use the client credentials grant flow. So you simply create an HTTP request (as you've written above already, take care to escape the GET parameters though) and get the response content. Your flow does not use redirects, so simply parse the JSON object in the response content, e.g. with the org.json library. Finally, send an HTTP request using the extracted access token.
Note that your examples are not completely standard compliant. The standard requires using HTTPS, sending the token in an HTTP header instead of a GET parameter and suggests using a HTTP basic authorization header instead of GET parameters to specify client credentials.
I may have misunderstood your question, and you may want to implement the server side, too. The scribe library supports only client side, so you can find a commercial implementation or implement your own server. It is a complex task, but if you support only the client credentials flow, it almost becomes easy. ;-)
This isn't a plugin, it's just a sample Grails application that acts as an OAuth provider. It was really easy to get up and running with Grails 3.
https://github.com/bobbywarner/grails3-oauth2-api

How can I use OAuth to replace OpenID for federated login

I am currently using OpenID as a relying-party to implement federated login on a website I'm developing. However cursory Google searches indicate that OpenID does not play well with web-services which I'd like to expose. However every tutorial, explanation or library seems oriented towards gaining access to a resource held by a 3rd party, Flickr library, Gmail address-book etc. Is it possible to use OAuth for this or am I barking up the wrong tree?
OAuth is not an appropriate technology to use here.

Resources