OriginHeaderDoesNotMatchKey w/ Successful Auth Code

[ckhicks]

I really hope that I'm missing something simple here. I can get a valid auth code with the proper state parameter back from my application, but when I try to hit /Platform/App/GetAccessTokensFromCode I get the following:

ErrorCode: 2107
ErrorStatus: "OriginHeaderDoesNotMatchKey"
Message: "Origin header does not match the provided API key."
MessageData:
  Origin: "https://auth.starsidefoundry.com"
ThrottleSeconds: 0

My app has an Origin Header as follows:

Here's my token request using jQuery:

$.ajax({
  type: 'POST',
  url: 'https://www.bungie.net/Platform/App/GetAccessTokensFromCode/',
  headers: {
    'X-API-KEY': '[redacted]'
  },
  data: JSON.stringify({
    'grant_type': 'authorization_code',
    'code': [code from url param]
  }),
  complete: function(res) {
    console.log(res);
  }
});

...what am I missing? 😆

[ArkahnX]

Try having the post body in this format "grant_type=authorization_code&code={authCode}"

[iBotPeaches]

Try having a read with #61 and #55 - It's possible the URLs you are using might not be trailing a slash and/or not including www which would a cause a redirect and drop some important headers in the process.

[ckhicks]

Iiiiinteresting - when dropping the trailing slash I get:

Mixed Content: The page at 'https://auth.starsidefoundry.com/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://www.bungie.net/Platform/App/GetAccessTokensFromCode/'. This request has been blocked; the content must be served over HTTPS.

Now I'm curious about trying a few different paths in case it is indeed a redirect issue. Thanks for the help this far!

[iBotPeaches]

Heres a few things to check for all endpoints.

1. SSL (so https://)
2. www included to prevent a redirect
3. Trailing slash

IE - https://www.bungie.net/Platform/App/GetAccessTokensFromCode/

Forgetting any of those cause Bungie to do a redirect to proper one, which sometimes drop valuable header information.

[ckhicks]

Hmm, now I'm getting valid tokens, which I'm attempting to put to good use via Auth0.com tools. Here's what I get back from them for the OAuth flow so far:

{
  "token": "CIweEoYCACC176mGymsz1oO0Cl7p2nWvT9+DKbGeqJ30sYtCBPqASeAAAADVePEPGYD/ZIQL8BsHGCEiVex2BIedhYRwXBwzeDOlIn0Vo9dfJucSk/d7QVm/9flSi4T8dsT+QRoZQRKTTdLwjDUCec9VA5B8uafgQxCq+N7NjZuGv8TwUryaWijsnl42p5Vz29Ciz9UBxYxcj9rLveG+ng1xpoWQHT5pk5CK32ApB2QEQPxGCmrxXEDOL+1ZJbkqyXeTElMflDEDQEsgV/nC9B31j75E/228PGM1YwXyGjC4viHSkKUkL8uJ9w+IapENdsVRNXu/r/dzoaf8bjzuy3y98uTGWU9s9WfFWw==",
  "clientID": "kS5HDblS834wO4h60BE9SLHAutJWDwOC",
  "updated_at": "2017-09-08T19:23:48.140Z",
  "name": "",
  "picture": "https://cdn.auth0.com/avatars/default.png",
  "user_id": "oauth2|Bungie|undefined",
  "nickname": "",
  "identities": [
    {
      "provider": "oauth2",
      "user_id": "Bungie|undefined",
      "connection": "Bungie",
      "isSocial": true
    }
  ],
  "created_at": "2017-09-08T16:27:14.808Z",
  "ctx": {
    "token_type": "Bearer",
    "expires_in": 3600,
    "refresh_expires_in": 7776000,
    "membership_id": "50839"
  },
  "sub": "oauth2|Bungie|undefined"
}

If anyone is interested, here's my "custom extension" I have over there to handle the authorization:

I'm going to keep pushing down this road and see if I can get a successful transaction to take place and tokens stored in my app. I'd really like to use Auth0 to handle the entire OAuth process, if only because it'd be so much faster for future devs to get up and running with a browser app. Thanks again to all who have dropped hints and fixes so far!

[destefanis]

I was also having this issue when using the fetch API. The response origin the request returns is also "null" so that doesn't really help. For the time being I've set my origin to * while I work locally, but I'd also love to see a long term fix.

[ckhicks]

Making really good progress - I'll be posting examples using Auth0 if I can get this last step working. I'm trying to get a refresh token using the following:

request.post({
    url: 'https://www.bungie.net/platform/app/oauth/token/',
    form: {
      'grant_type': 'refresh_token',
      'refresh_token': [my access token]
    }
  }, function(err, res, body){
    if (err) return callback(err);
    if (res.statusCode !== 200 ) return callback(new Error('StatusCode:' + res.statusCode));
      callback(null, JSON.parse(body));
});

When I post this immediately after receiving a valid access token from my authorization code, however, I get this:

{
  "error": "invalid_request",
  "error_description": "StatusCode:400"
}

I'm using the exact same endpoint for my initial token request and the refresh. Any ideas?

[ckhicks]

Okay, I think that I'm getting a valid refresh token back now, but when I make a protected call I get the following: 401 - Unauthorized: Access is denied due to invalid credentials.

Here's my AJAX call:

$.ajax({
  type: 'GET',
  url: 'https://www.bungie.net/Platform/Destiny2/1/Profile/4611686018435819655/?components=101',
  headers: {
    'X-API-KEY': [redacted]',
    'Authorization': 'Bearer ' + [token]
  },
  data: '',
  complete: function(res) {
    console.log(res);
  }
});

[floatingatoll]

Can you inspect the response for a Cookie header and dig out the 'bungled' value? I think that's what Thorn et al. can use to see, server-side, exactly why you were refused.

…

On Sun, Sep 10, 2017 at 9:29 PM, CK Hicks ***@***.***> wrote: Okay, I *think* that I'm getting a valid refresh token back now, but when I make a protected call I get the following: 401 - Unauthorized: Access is denied due to invalid credentials. Here's my AJAX call: $.ajax({ type: 'GET', url: 'https://www.bungie.net/Platform/Destiny2/1/Profile/4611686018435819655/?components=101', headers: { 'X-API-KEY': [redacted]', 'Authorization': 'Bearer ' + [token] }, data: '', complete: function(res) { console.log(res); } }); — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#71 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFqDDNSlgNmgUQvA4_asmOansa52L09ks5shLcsgaJpZM4PQs8r> .

[ckhicks]

Ooooookay, I think I have this figured out using client-side scripts to get/refresh tokens. Thanks to everyone for the help - this kinda opened up a new set of needs for JS solutions that provide an easy auth flow. I'm considering filling that with a free service of some kind so others can just jump in and build. More later!

[vthornheart-bng]

Hmm, yeah share here what the issues ended up being and how you worked around them - if there's things we can do on our side that aren't meeting oauth spec for example and are preventing this from working without a hassle, perhaps we can help!

[ckhicks]

Yeah! See the screenshot above for the the Auth0 configuration I used in a "Custom Social Extension" for the initial OAuth handshake. I then captured that using their embed tools as follows:

<button onclick="lock.show();">Login</button>
<script src="https://cdn.auth0.com/js/lock/10.20/lock.min.js"></script>
<script>
  var lock = new Auth0Lock(
    'Ni1nn2KdlmmP1iA6V9RPbPgj0Pzb5cgh',
    'starsidefoundry.auth0.com',
    {
      auth: {
        redirectUrl: 'https://auth.starsidefoundry.com',
        responseType: 'token',
        sso: false
      }
    }
  );
  // Listening for the authenticated event
  lock.on("authenticated", function(authResult) {
    lock.getUserInfo(authResult.accessToken, function(error, payload) {
      if (error) {
        // blam!
      } else {
        console.log(payload);
        // looks like we have a token, let's put it to use!
      }
    });
  });
</script>

...which I then promptly broke as I dug into protected resources and refreshing my own tokens after expiry. 🙈

I left a few more notes on #45 as well, but what's frustrating for client-side authorization is the desire to keep secret things secret, while also making sure new devs can spin up their toolsets easily. Passing the various headers and body parameters isn't intuitive, though I'm sure it complies with spec just fine. I have a heart for folks wanting to jump in and build so long as they know the basics.

Honestly, what I'd love to do is see what the DIM crew has made become something plug-and-play. Wrapping that in a small library that devs could drop into their JS apps could make things a lot simpler for the next wave of ideas to come to life.

As always...thanks so much for your assistance. I can't say how cool it is to play and dev Destiny at the same time. Sometimes I don't know which is more fun!