Skip to main content

Securely redirects OAuth responses to known clients.

Project description

Description

During the OAuth workflow a webserver defined by redirect_uri receives the result of a the authorization given by the enduser.

This redirect_uri is usually a whitelisted uri to avoid phising attacks.

Unfortunately this makes it hard to write an OAuth integrated client to an API where the domain is not known in advance.

Faced with such a situation we wrote this server to move the decision of who can receive the result of an OAuth handshake from the OAuth provider to an intermediary.

How it Works

Using oauth_redirect the OAuth workflow works as follows:

  1. The oauth_redirect server is run on a TLS protected site. For example: https://oauth.seantis.ch.

  2. The OAuth provider is configured to allow redirects to https://oauth.seantis.ch/redirect.

  3. The client that wants to acquire the authorisation registers itself with the oauth_redirect server using a secret authentication code.

  4. The enduser is presented with the OAuth authorization site, with the redirect_uri set to https://oauth.seantis.ch/redirect.

  5. The result is sent to the oauth_redirect server, which will forward/proxy the request to the client, if and only if the client has registered itself before and the request from the OAuth provider contains a token to that effect.

Methods

POST /register/<authentication code>

Used by the client/authorisation seeker to register itself. The client is required to include a secret authentication code in the registration message.

The body of the POST request is a json in this form:

{
    'url': "The url that handles the forwarded OAuth response.",
    'method': "The method with which the url should be called (get, put or post).",
    'success_url': "The url the server redirects to if the handler url returns a 2XX code.",
    'error_url': "The url the server redirects to if the handler url returns a non-2XX code.",
    'ttl': "The optional time to live in seconds (defaults to 3600 seconds)",
    'secret': "A client-specific secret that should be used authenticate
    the forwarded request. If the request does not contain this secret,
    someone other than oauth_redirect has sent it.",
}

Returns the token which needs to be passed by the OAuth provider:

{
    'token': "..."
}

(GET|POST) /redirect

The endpoint communicated to the OAuth provider through the redirect_uri. To authenticate the request coming from the OAuth provider must contain the token given by /register/<authentication code>.

Usually OAuth providers provide some kind of of value that may be passed from the client to the redirect_uri. This value can be used to carry the token back to the oauth_redirect server.

If there is no such value, the token may also be passed by url, using query paramters (i.e. https://oauth.seantis.ch/redirect?token=…).

Any value will do, a value in a json body, a formdata value or a query parameter.

If the redirect request is accepted it is proxied to the registered url. The result of the /redirect request is the result of the proxied url.

If the request was accepted, it is deleted.

Deployment

The server is implemented using aiohttp. It requires at least Python 3.5.

Though it might be possible to implement TLS support on the oauth_redirect we recommend that you put it behind a proper web proxy like nginx/apache.

To run the server run:

oauth-redirect --host localhost --port 8080 --database registered --auth <your custom auth code>

Run the Tests

Install tox and run it:

pip install tox
tox

Limit the tests to a specific python version:

tox -e py27

Conventions

Oauth_redirect follows PEP8 as close as possible. To test for it run:

tox -e pep8

Oauth_redirect uses Semantic Versioning

Build Status

Build Status

Coverage

Project Coverage

Latest PyPI Release

Latest PyPI Release

License

oauth_redirect is released under GPLv2

Changelog

0.3.0 (2017-05-24)

  • Adds the ability to define a success and an error url. [href]

0.2.0 (2017-05-24)

  • Adds the ability to define the HTTP method with which the redirect target should be called. [href]

  • Adds support for GET in addition to POST for the redirect view handler. [href]

0.1.0 (2017-05-23)

  • Initial Release. [href]

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

oauth_redirect-0.3.0.tar.gz (8.2 kB view details)

Uploaded Source

Built Distribution

oauth_redirect-0.3.0-py3-none-any.whl (12.4 kB view details)

Uploaded Python 3

File details

Details for the file oauth_redirect-0.3.0.tar.gz.

File metadata

File hashes

Hashes for oauth_redirect-0.3.0.tar.gz
Algorithm Hash digest
SHA256 28b0fecace708df8093af79fee29ff5c17d5689e750343a8adf727afdb895242
MD5 40abb8fa1c61418167d96ad5fa16c954
BLAKE2b-256 c16b816225d1425ecb5664b76f716dc7e74ea239f45110b1be53eabf5dc869ff

See more details on using hashes here.

File details

Details for the file oauth_redirect-0.3.0-py3-none-any.whl.

File metadata

File hashes

Hashes for oauth_redirect-0.3.0-py3-none-any.whl
Algorithm Hash digest
SHA256 f2c0ca2b0d870d70a220a2d27855534e18267e3cf65fb7430bec1a57af9dcb41
MD5 4769222313a7450fa36265e9debb0b45
BLAKE2b-256 4b97a3f36c39b53318ad1432b1b4f286cedbc616061ad47d92a5650c2e6b574d

See more details on using hashes here.

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page