401 Unauthorized when Requesting an Access Token


(Von Villafuerte) #1

I am using .NET and I am able to get the “code”. When I use it to request for a token, using a valid dev key and secret, I keep on getting an Unauthorized error. I can tell that the dev key and secret are valid because it works on the playground. I made sure that the dev key and secret are in the authorization header when I made the call to the API. What else am I missing?


(Pav) #2

I do not have any .NET examples. But I am guessing the problem is how you are communicating in getting the token.

I posted something the other week in PHP which uses a Form (GET) to Authorize and cURL (POST) to get the tokens.

Hopefully that gives you some guidance.


(Von Villafuerte) #3

There’s a .NET example here that is basically what I’m doing. I even added an authorization header and it’s not working either. Although I can see that in your cURL sample that it’s not adding in an auth header.


(Bradley Booth) #4

I would double check that the redirect_uri matches what you registered with in the developer portal, and that it matches the initial authorization code request. If they don’t match then you will get a 401. The spec might help out as well https://tools.ietf.org/html/rfc6749#section-4.1.3


(John Borelli) #5

I’ve verified that the redirect uri does not have to be the same as mashery. I have had authentications run from one server and send the results (redirect uri) to a completely different one. If he is getting an “unauthorized” message that is almost exclusively due to not getting an authorization token (or not using it fast enough) to present during the client auth request.


(Bradley Booth) #6

Correct, right now we have validation turned off as far as getting an authorization code with the provded redirect_uri in the Mashery. However you need to have the same redirect_uri for the Authorization and Access Token requests.


(Von Villafuerte) #7

I’ve checked that already and I think it won’t cause the 401 because the authorization works on the playground, which has a different URL than my redirect URL. Thanks for the input though @bradb.


(Von Villafuerte) #8

What do you mean by “not using it fast enough”? How fast is fast? In our code, once we got the “code” back from Infusion we post the needed data to acquire a token right away. The time from the code was received to the time our POST request was initiated was about a couple of seconds or even less.


(Bradley Booth) #9

All I am saying is that the call to the authorization endpoint has a redirect_uri. When you get a code the same redirect_uri needs to be sent to the token endpoint to exchange the code for an access token. Just make sure they use the same redirect_uri. The Authorization in the playground handles this for you.


(Von Villafuerte) #10

Thanks for the clarification @bradb. I made sure I am using the same redirect_uri for both endpoints as the value is coming from a common function. Any more ideas what am I missing in my code that causes the Unauthorized error?


(John Borelli) #11

The auth token is only good for a very short time (it’s meant to be used right away to get the access/refresh tokens). I’ve heard varying numbers but most say about 5 minutes.


(Von Villafuerte) #12

If it’s five minutes then “not using it fast enough” is not the issue. I’m stuck.


(Pav) #13

I thought the Auth Token was available for 60 minutes? Or has something recently changed?


(John Borelli) #14

I haven’t tested it. That’s what I’ve seen as the most common response to the question though.


(Bradley Booth) #15

Authorization Codes are currently configured with a TTL of 24 hrs. Same with the Access Token.


(Ege Fitness) #16

I tested. No problem. :ok_hand: