I have been studying the DriveAPI for a while now and can't seem to find a simple way to get it to work just for MY needs only...
I would like to use the DriveAPI only with just the REST API (HTTPS).
There are many things like token, clientid, apikey, secrets, etc.
All I need, is to search MY OWN GDrive files (FULLTEXT CONTAINS) and get a result from the API but I can't get it to work.
Please remember, this is for my own needs only and I would like to bypass the verification (login) window and get some kind of token, that lasts forever, so I can implement this in my own tool.
So, how can I authenticate and use the DriveAPI with just plain HTTPS?
My efforts so far:
I have already made a client ID and a client KEY for a sample project in the dashboard. I have also an Google Drive API KEY. From this point, I don't really know where and what to send.
As I mentioned in my comment, there is no "bypass" for the OAuth 2.0 authentication (that's why there is authentication enforced in the first place). Have you done any coding for this that you can share? For most REST API's OAuth 2.0 authentication is required. Your application must be able to request the token and use it to make the requests.
Google API's use Google Identity service to provide the tokens. In the following document there are many examples of how this implementation should be done in different programming languages:
https://developers.google.com/identity/protocols/OAuth2WebServer
Related
I want to add "Sign-in with Google" as an alternative to creating an account when signing up for our services.
I want the process to retrieve the user's email address and name. That's it.
And this example was all I needed
https://developers.google.com/identity/sign-in/web
Worked great. Very similar to Log in with Facebook, which I added last week.
But now I read that it won't be supported after March 2023.
Using the destined-for-the-dustbin JS code, I can get back useful info about the account I'm logging in with.
ID: 10855600*******690837;Frank;Hart;frank.hart*****#gmail.com
The parameter passed to the callback function has a getBasicProfile() method which does the job
var profile = googleUser.getBasicProfile();
But using the new code, I found (by trial and error) that the parameter passed to the callback function is an object, which has three fields, the only potentially useful one called credential, with content such as:
eyJhbGciOiJSUzI1NiIsImtpZCI6IjQ2Mjk0OTE3NGYxZWVkZjRmOWY5NDM0ODc3YmU0ODNiMzI0MTQwZjUiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJuYmYiOjE2Mjg4NTQzOTcsImF1ZCI6IjY1MjE0Nzk1NjY0My05aWVmdHN2bmZraDVma2x1NHUxOGg1Ymc3MDA0YjdsOC5hcHBzLmdvb2dsZXVzZXJjb250ZW50LmNvbSIsInN1YiI6IjEwODU1NjAwNDY3OTg0NzY5MDgzNyIsImVtYWlsIjoiZnJhbmsuaGFydDA0N0BnbWFpbC5jb20iLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiYXpwIjoiNjUyMTQ3OTU2NjQzLTlpZWZ0c3ZuZmtoNWZrbHU0dTE4aDViZzcwMDRiN2w4LmFwcHMuZ29vZ2xldXNlcmNvbnRlbnQuY29tIiwibmFtZSI6IkZyYW5rIEhhcnQiLCJwaWN0dXJlIjoiaHR0
Now, my guess is that I have to send that string to my server, and do something with it, possibly involving the "Client secret" that is associated with the App on developers.google.com. But I've been looking most of the day, and I'm not sure if what I've found is necessary - I hope it isn't
https://developers.google.com/identity/sign-in/web/backend-auth
Do I now need to become an OAuth2 programmer just to add a Sign-in with Google button?
The good news is that you do not need to learn OAuth2, you do not need to follow the backend-auth guide linked in your question. This migration actually removes the complexity OAuth2, access and refresh tokens from sign-in. Yes, there is the difficulty of learning and understanding the new and different way of securely sharing the user profile. Hopefully, after cresting over the learning curve you'll see how this makes working with a profile more simple.
JSON Web Tokens (JWTs) are now used to securely share the Google Account profile.
That big pile of text--the credential, it is a base-64 encoded and a JWT.
jwt.io has an online JWT decoder that's handy for testing and a nice writeup of working with JWTs. After decode its just a JSON object, no get methods are necessary, just access the individual fields.
All this said, you need to decide whether decode should take place in the user's browser, or on your backend server. This depends upon how you're working with the profile and your setup. Typically, you'd decode on your server after a redirect using data-login_uri in HTML or login_uri in JS.
There are a large number of JWT decode libraries available, so it's very likely you'll be able to add a JWT library, decode it and you're all set to access the individual fields in the credential.
I've got a Paw project for an API that uses OAuth 2. Everything works great, on a per request basis, but every request manages its own token. Is there a way to have a single OAuth 2 "manager" for each project, where each request can grab the latest token from that manager, rather than grabbing new tokens for each request?
Environment variables are a nice way to handle this. We've described this in the docs:
As you may often switch between development and production environments, or between several users, you may need to have several OAuth credentials you may apply to your Requests. You can keep those credentials in Environments, and then use them in the OAuth Header Dynamic Value.
Read more about Environments and how to use Environments as Reusable Presets (this actually is the doc article that can help you the most for that).
Scenario: Auth0 Single Page application client. .NET Web API and Angular SPA both configured to use this client. Works great.
I'd like to add Azure API Management as a layer in front of the API. Have set up the API in the Management Portal, updated SPA to call API, tested calls from SPA, works great.
Now, I'd like to configure API Management Portal with the right security settings such that people can invoke API calls from the Developer Portal. I've used this [https://auth0.com/docs/integrations/azure-api-management/configure-azure] as a guide.
Where I'm at:
From the Developer portal, I can choose Authorization Code as an Auth type, go through a successful sign-in process with Auth0 and get back a Bearer token. However, calls made to the API always return 401. I think this is because I'm confused about how to set it up right. As I understand it:
either I follow the instructions and setup a new API client in Auth0, but if that's the case then surely it's not going to work, because tokens generated from one client aren't going to work against my SPA client? (or is there something I need to change to make it work)
or, how should I configure Azure API Management to work with a SPA application. (this would be my preferred method, having two clients in Auth0 seems 'messy'). But, don't I need an 'audience' value in my authorization endpoint URL? How do I get that?
If anyone has done this, would very much appreciate some guidance here.
Well, I didn't think I'd be back to answer my own question quite so soon. The reason is mostly rooted in my general ignorance of this stuff, combined with trying to take examples and fuse them together for my needs. Posting this to help out anyone else who finds themselves here.
Rather than take the Single Application Client in Auth0 and make it work with Azure API Management, I decided to go the other way, and make the non-interactive Client work with my SPA. This eventually 'felt' more right: the API is what I'm securing, and I should get the API Management portal working, then change my SPA to work with it.
Once I remembered/realised that I needed to update my audience in the API to match the audience set in the Client in Auth0, then the Management Portal started working. Getting the SPA to work with the API then became a challenge: I was trying to find out how to change the auth0 angular code to pass an audience to match the one the API was sending, but it kept sending the ClientID instead. (by the way, finding all that out was made easier by using https://jwt.io/ to decrypt the Bearer tokens and work out what was happening - look at the 'aud' value for the audience.
In the end, I changed my API, in the new JwtBearerAuthenticationOptions object, the TokenValidationParameters object (of type TokenValidationParameters) has a property ValidAudiences (yes, there is also a ValidAudience property, confusing) which can take multiple audiences. So, I added my ClientID to that.
The only other thing I then changed (which might be specific to me, not sure) is that I had to change the JsonWebToken Signature Algorithm value in Auth0 for my non-interactive client (advanced settings, oAuth tab) from HS256 to RS256.
With all that done, now requests from both the API Management Portal, and my SPA work.
Curious to know if this is the "right" way of doing it, or if I've done anything considered dangerous here.
Since you're able to make the validation of the jwts with the .Net API work, Only few changes are actually necessary to get this working with Azure API Management.
In API management,
Create a validate-jwt inbound policy on an Operation (or all operations)
set the audiences and issuers the same as what you've used with your .NET web api. (you can check the values in Auth0 portal if you don't know this yet)
The important field that is missing at this point is the Open ID URLs since auth0 uses RS256 by default. The url can be found in you Auth0 portal at: Applications -> your single page application -> settings -> Scroll down, Show Advanced Settings -> End points. Then copy the OpenID Configuration
Here's the reference for API management's requirement for JWT tokens
optional reading
I have built a Restful Web API for my (android) mobile application, and now i am trying to secure the access to the API. I was reading for about a week on this topic and i got the whole spectrum - from those who say that is is impossible to secure a Restful API to those who say that Https (SSL) is enough.
Here I don't want to start a discussion about that.I have settled with OAuth or OAuth2 it doesn't matter(as far as I have read OAuth seems to be the better choice, but in the Microsoft tutorials they use OAuth 2, so here i am quite confused), and yes i know that they are completely different, but I am so frustrated of searching that I would accept either (I must admit that I expceted this to be much easier). As I said, I was searching for about a week, and all I got are concepts(a lot of them). You send some data -magic start - usually username/password to the server, your data is being processed and you get a token back - magic stop-. On SO there are a lot of questions on this topic but most of the answers are unprecise (and unfortunately unusuable). For example I got this one How to secure WEB API, nice answers, but not really use of them, or this one Implement Web API with OAuth and a Single Page Application. I also got the examples from the Microsoft tutorials but there is a lot of overhead in the code and the part about OAuth isn't quite clear(which is unfortunate because the whole example should be about OAuth). I could post tons of links which claim to talk about this topic, but actually they are of no help.
What I am looking for is an simple, very very simple, example of an ASP.NET OAuth(2) implementation. It would be great if I just could use it with fiddler, provide an username/password in the header and with use of grant_type: xxx I get the token back(the permitted username/password can be hard coded inside the project, so no need for Entity framework implementation or any database on the backend). And it would also be great if someone could explain me how to use this token to authorize the user (I got it that I have to provide the Controller functions with the [Authorize] attribute, but how and where is this token-check being done ?). But please, don't post any theory about OAuth, I don't need that, here I am looking for the actual implementation of OAuth inside of Asp.Net Web Api
thanks
Here is detailed post about adding the resource owner password credentials flow for your Web API project.
The most simple implementation of OAuth2 in Web API project you can find here:
WebApiOAuth2 on GitHub
There are just two important files:
Startup.cs (with settings)
AuthorizationServerProvider.cs (authorization of users using oauth2)
I've been using Tweepy for OAuth and twitter API calls. For a whole bunch of reasons, I'm switching to urllib and making HTTP requests directly.
It appears have two options:
I can do oAuth directly over HTTP, but the existing resources seem to either say "don't bother, just use a library," or they don't cover half of the process.
I can continue using Tweepy to get a key/secret pair, but from there I'm still not clear on how to use that pair to authenticate my queries. Specifically, what do I have to do before "https://api.twitter.com/1/statuses/home_timeline.json" to authenticate, supposing I've already completed the OAuth process and have a key/secret for the user I want.
Why don't you use a more generic oauth library (like oauth2), instead of throwing out the oauth authentication library idea entirely?
https://github.com/simplegeo/python-oauth2
Signing a request for OAuth means either implementing the signature function yourself for each request or using an existing library - and creating oauth signatures is pretty complicated and prone to breakage. As someone who's supported OAuth-based APIs for a couple of years I strongly encourage you to use a library.
The oauth2 library has an example for getting a token/secret for twitter.
Once you've gotten the token and secret, the oauth library is as simple as:
consumer = oauth.Consumer(consumer_key, consumer_secret)
token = oauth.Token(token,secret)
client = oauth.Client(consumer,token)
response = make_request(client,"https://api.twitter.com/1/statuses/home_timeline.json")