0

I have a use-case where I need to spoof a white-listed Redirect URL locally when performing OAuth 2 authentication.

I'm running a very basic web-server coupled with a hosts file entry for the domain I'm spoofing. I'm able to correctly negotiate my tokens and return them to Paw, but Paw isn't picking up my access_token or refresh_token, it simply displays the raw response:

Paw authentication window

Here's my server code (with placeholders for sensitive data):

var http = require('http'),
    request = require('request');

var PORT = 6109;

var server = http.createServer(function(req, res) {
    var code = req.url.split('?')[1].split('=')[2];

    request({
        url: 'https://<access token URL>/oauth2/token?code=' + code,
        method: 'POST',
        form: {
            'client_id': <client_id>,
            'client_secret': <client_secret>,
            'grant_type': 'authorization_code',
            'redirect_uri': <spoofed redirect URL>
        }
    }, function(err, response, data) {
        data = JSON.parse(data);

        res.writeHead(200, {'Content-Type': 'application/json'});
        res.write(JSON.stringify(data.result));

        // I also tried this with the same end-result
        // res.writeHead(200);
        // res.write('access_token=' + data.result.access_token + '&token_type=' + data.result.token_type + '&refresh_token=' + data.result.refresh_token);
        res.end();
    });
});

server.listen(PORT, function() {
    console.log('Server listening on port %d', PORT);
});

What am I missing? Why isn't Paw finding my tokens?

Here's my configuration for reference:

oauth configuration

Some other noteworthy points:

  • The OAuth provider is non-standard and flubs quite a few things from the spec (my proxy exists in part to patch up the non-standard bits)
  • The domain for the Redirect URL is real, but the URL does not resolve (this is a part of the reason for the local hosts entry)
  • I'm not showing this part of the flow, but I am correctly completing the authorization step prior to being given the code value
André Dion
  • 21,269
  • 7
  • 56
  • 60

2 Answers2

1

I think you're probably confused between the Authorization URL and Access Token URL. When you're in Authorization Code grant type for OAuth 2, you're expected to have a user confirmation step in a web page (the Authorization URL).

Which makes me guess that instead, you're expecting instead to use the Password Grant or Client Credentials? Otherwise, if you want to use Authorization URL, you'll need to specify a webpage at the Authorization URL.


Note: I've tried your Node.js script in Paw using the two last grants I mentioned (Password Grant & Client Credentials), and it works nicely.


Update: Following the comments below, I understand more what you are doing. The Authorization Request should (if successful) return a 302 redirect response to the Redirect URL page, and append a code URL query param to it. It seems like you're returning a JSON response with the code instead, so Paw isn't catching it.

According to the OAuth 2.0 spec (RFC 6749), section *4.1.2. Authorization Response*, if granted, the code should be passed as a URL query param (i.e. a ?key=value param in the URL) to the Redirect URL when doing the redirection.

If the resource owner grants the access request, the authorization server issues an authorization code and delivers it to the client by adding the following parameters to the query component of the redirection URI using the "application/x-www-form-urlencoded" format

Quoting the example from the spec, here's how the response of the Authorization Request should look like if it's a success (code is granted):

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
           &state=xyz
Community
  • 1
  • 1
Micha Mazaheri
  • 3,481
  • 1
  • 21
  • 26
  • It's highly possible I am confusing terminology, but I do need the Authorization Code grant type and not the other grant types you mentioned. Please refer to the attached screenshot of my authentication configuration in my updated question, if that sheds any additional light on what I'm trying to do. – André Dion Sep 02 '16 at 16:46
  • I should also mention that I do see and pass the authorization step. I am getting tokens after-all—if I manually copy/paste the tokens from the response into the corresponding auth fields, everything works. The issue I'm facing is that the tokens are not automatically populating those fields. – André Dion Sep 02 '16 at 17:12
  • Sorry for the late answer! I think there's some confusion… In grant type "Authorization Code" the code should be passed to the 3rd party (here, Paw) via a URL param. Then the client app is responsible to fetch a token via a headless HTTP request (not a webview). But here your Authorization URL is showing (or redirecting to) the "access_token" directly. Here Paw is still waiting to find the "code" value in the URL param of the redirection URL. – Micha Mazaheri Sep 07 '16 at 10:59
  • I also noticed this, Micha, and tried to give Paw the code as well, but it simply displays it in that waiting window. I can't seem to get Paw to actually pick up any data. – André Dion Sep 07 '16 at 11:30
  • The `code` should be a URL query param in the redirection to the Redirect URL. It means upon success, the Authorization URL should return a `302 Found` redirection to the Redirect URL, passing the `code` as a URL param (instead of putting the code in a JSON body as I think you're doing). Please refer to the OAuth 2 spec, section 4.1.2 https://tools.ietf.org/html/rfc6749#section-4.1.2 `[the server] delivers it [the code] to the client by adding the following parameters to the query component of the redirection URI` – Micha Mazaheri Sep 08 '16 at 08:12
  • 1
    I tried the steps that you've added in your update, but must have botched the payload. The key to get this working was the missing `Location` header for the `302`. @MichaMazaheri, thanks for the time you take personally to help the users of your software! – André Dion Sep 08 '16 at 12:02
0

I saw that the Redirect URL contains "my Spoofed Uri".

When we need to use authorization code flow, we provide the authorization code and redirect Uri.

When the URI you are providing does not match the URI saved for the client in Identity server, you will not be able to get the token as the URI does not match with the client authorization code.

For example : Consider client identity in the Identity server be: Auth Code: "xyx" Redirect Uri: "www.mylocalhost.com\xyz"

And in your example the combination you are providing is: Auth Code: "xyx" Redirect Uri: "<my spoofed uri>"

As these 2 wont match there will be no token received.

I believe if you use the correct URI that is registered with the client in the Identity server, you will be able to receive the token.

Mitra Ghorpade
  • 717
  • 4
  • 8
  • I *am* getting tokens...they're right there in my question. Those are correctly delivered by the OAuth provider. `` is just me editing out the real URL as that is private information I do not wish to expose here. – André Dion Sep 02 '16 at 18:47