How can I sign OAuth with proxy - python

Twitter, Facebook and some other websites are blocked in my country.
And I want to call the open API to do some hacking. I have searched but it can't solve my
problem. Any python libraries can help me sign the OAuth request through proxy and get
the access token ?
Thanks.

I am guessing you will have to set up your own proxy service for this, i.e set up your entire API and OAuth logic on a server outside your own country. If you call this proxy service from within your own country it is probably not apparent that you are actually communicating with Twitter.
You will need some sort of cryptographic layer between your client and your proxy/relay service though to make it somewhat secure/obscure. Your own request signing mechanism so to say, and your proxy/relay endpoint should definitely talk (HTTPS/SSL).

Related

Python AuthLib Resource Server using a BearerTokenValidator with Multiple Strategies

I have a resource server (built with Flask, but not sure if that matters right now) that has a RESTful API. The API is secured with OAuth2 access tokens and scopes.
Currently the access tokens are opaque (not JWT) and the resource server needs to call the /oauth/token/info endpoint on the auth server to check if the access token is valid and get the list of scopes associated with the access token, and then validate the scopes granted against the ones required. We have some custom code for this.
We now want to start to use JWT access tokens so that we can avoid this call to the auth server, but we can't roll them out to all OAuth clients just yet, only some. So the resource server will be getting a mix of opaque access tokens and JWT access tokens. The JWT will be signed with a RS256 private/public key, and the public key will be available from the auth server at a /oauth/discovery/keys endpoint that the resource servers could hit on startup once and cache so that it doesn't need to hit it on every request, unless the public key changes and doesn't match the kid in the JWT.
While doing this, I was hoping we could get rid of some of the custom code we've written and use some tried and tested library for us, hence AuthLib.
However, I can't seem to find any good examples of how to configure a resource server to handle either of these cases individually, let alone both at the same time. The examples I see seem to assume the resource server has access to the access token database.
I'm assuming I will need to write my own BearerTokenValidator that handles this, but I was hoping there would be examples somewhere on how to go about that. Ideally with the ability to cache the public key for the JWT and only refresh when the JWT kid claim changes.
I was sort of hoping that a TokenInfoBearerTokenValidator and a JWTBearerTokenValidator existed that I could use that did most of the work for me. Maybe there are and I'm just missing it?
AuthLib 1.0 has been released with additional support fro JWTBearerTokens that makes this easier to accomplish now.

How can I get the URL of the request sender to my API?

I'm trying to secure my API routes with API keys and website URL of the client.
I'm using the tuple (api_key, website_url) to grant the access to my API. In fact, the website URL is sent in the request. Example: using Angular httpClient
this.restPost(this.endpoint,body,options)
the options include: the API key and website URL.
How can I check if the website_url inserted in the options matches the URL of the request sender? I'm using Flask microframework in the backend.
What you are asking for is impossible.
Fundamentally, if requests are coming to you across the public internet, you cannot know the identity of the application sending requests to you.
You can make an educated guess about the remote client. But since the remote client is running on a platform you can't control, nothing prevents an attacker from reverse engineering how it works and then sending you identical requests. You won't be able to tell the difference if the attacker is skilled enough.
There are tools that can help you detect and block malicious clients, but there are also tools for malicious clients to evade detection (just search Stack Overflow for many examples of the reverse problem). It's an arms race and if you want to win you will need to invest more time and money than your counterpart(s) on the other side are.
The normal solution to this problem is to make it your clients' problem. Charge them for a quota of API requests, and bill them if they make more than that. Then if they share the API key with someone else, they also need to pay the bill for them. Then you don't need to care whose API key it is: you're getting paid either way.
If you can't bill them (e.g. if it's a free service) then the next best thing is rate limiting. Don't allow more than, say, 10 requests in a second for a single API key.
If you're serious about this sort of thing, you probably don't want to reinvent the wheel. There are cloud-scale API gateway services out there. Pick one and use it to handle all your API key authentication and client throttling.

Django OAuth2 provider and resources on different servers?

I'm looking to set up Django to use OAuth2 to authenticate users for a service that I'm running, but I'm having a bit of difficulty understanding how the tokens are passed around.
I've been working my way through this tutorial: https://django-oauth-toolkit.readthedocs.org/en/0.7.0/tutorial/tutorial_01.html. I've been able to get a server up and running as the OAuth provider, and it seems to be working as it should. I'm able to log in to it and set up an application. The difficulty I'm having is figuring out how the various tokens are passed around.
Suppose that my OAuth provider is sitting on one server - let's call this Provider.com - and my service that I'm wanting authenticated is on service.com. When a user first tries to make a request to the service, they first need to authenticate against the Provider. So they click on a login button which directs them to Provider.com. They enter their credentials. If everything is set up correctly on the server, they should be presented with a prompt that gives them a chance to allow or deny Service.com from accessing their account on Provider.com. Supposing that they click Allow, they are then redirected to Service.com, and are given a token. On future calls to Service.com, they pass in the token, and are, in theory, able to make authenticated calls.
The problem I'm having understanding is this: At what point do the Provider and the Service communicate? If a call comes in to the Service, how does it know that the authentication token passed in with the call is valid? There's know way it could know that a particular token is valid unless: A) it recognizes that same token from a previous call which was also authenticated or B) it talks to the OAuth 2 provider and verifies the authenticity of the token.
A diagram like the one found here shows the process in the browser:
At the end of this, it has the Client App sending the authentication code, client id, and client secret to the OAuth2 provider. In the previously mentioned tutorial, it isn't really clear how this is actually done. In the tutorial, the provider and the service are on the same machine, and it would appear that they also share the same database.
This this brings about my question: How does one host a Django-based OAuth provider on a separate server than the resource/service being accessed? Is this possible?
From this other post, it indicates that this might not be possible: https://stackoverflow.com/a/26656538/1096385 Is that indeed the case, at least with the existing Django OAuth2 provider framework?
It depends on the oauth2 flow you're using. It seems like you're using authentication code.
In that case:
service.com sends the browser to provider.com for user authentication (uri contains service.com client_id and redirect_uri)
User authenticates on provider.com, then the browser is redirected to service.com's redirect_uri with a ?code parameter.
On your server side, handle this code parameter and ask for a token with it.
See https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#web-server-apps

RESTful API using OAuth where authentication tokens are sent as part of the HTTP request

I am pretty new to developing APIs. This is part of my class project and the goal is to create a RESTful API in python where the delegation is done via OAuth and these tokens should be sent as part of the HTTP request.
I was advised that I should create an API that involves delegating the OAuth model into a proxy-like approach where authentication tokens are sent as part of the HTTP request. What exactly does a proxy-like approach mean? Any ideas?
I would really appreciate if anyone could help me out with this and also on how to create an API (even if it is not python specific, I can take cue from that)
If you are new to REST services, then this link will be nice kick start for you.
You can find here how to develop a basic rest api in python and the same with authentication.
So what is OAuth?
OAuth can be many things. It is most commonly used to allow an application (the consumer) to access data or services that the user (the resource owner) has with another service (the provider), and this is done in a way that prevents the consumer from knowing the login credentials that the user has with the provider.
For example, consider a website or application that asks you for permission to access your Facebook account and post something to your timeline. In this example you are the resource holder (you own your Facebook timeline), the third party application is the consumer and Facebook is the provider. Even if you grant access and the consumer application writes to your timeline, it never sees your Facebook login information.
This usage of OAuth does not apply to a client/server RESTful API. Something like this would only make sense if your RESTful API can be accessed by third party applications (consumers).
In the case of a direct client/server communication there is no need to hide login credentials, the client (curl in the examples above) receives the credentials from the user and uses them to authenticate requests with the server directly.

Using Google AppEngine app as a OAuth provider

I'm using the Google AppEngine 1.3.4 SDK which offers to allow your application to act as a OAuth service provider (http://code.google.com/appengine/docs/python/oauth/). Setting up a standard application on my localhost and using the following:
Request URL /_ah/OAuthGetRequestToken
Authorize URL /_ah/OAuthAuthorizeToken
Access Token URL /_ah/OAuthGetAccessToken
The client application just gets sent to a page requesting to grant OAuth access even though no user is logged in. Clicking 'Grant access' results in a message saying 'OAuth access granted' with no tokens or anything exchange. Can't see how this could work when it's not even prompting for a login.
As this functionality is quite new I can't find much out there. I've created a OAuth provider before in Rails and know that you need a Consumer Key and Secret, something that seems to be lacking in GAE?
Any ideas on how to get OAuth working in a sample GAE project are most welcome.
I would hazard a guess that the SDK implementation simply grants access regardless. It's also possible you still have a dev_appserver login cookie. Either way, try it in production - it'll almost certainly request login in that case.

Categories

Resources