Does OAuthV2policy have a problem with certain non-http callback URIs?

[#1]

I'm using the OAuthV2 policy to generate an authorization code for 3-legged OAuth. It fails to validate the redirect_uri in the query parameter against the Callback URL defined in the Apigee application. Does this policy have a problem with certain non-http callbacks? The callback URL is of the format myurl://. The policy returns "Error" :"Invalid redirection uri myurl://".

[DChiesa]

I understand your question.

The policy returns "Error" :"Invalid redirection uri myurl://".

The policy does not enforce an http/s scheme. If you have a custom scheme, such as myurl:// or oob: or whatever.... there's no problem.

A couple questions for you:

1. Have you registered the callback URL for the Developer App?
2. What grant_type are you using?
3. When do you see the error? At the time you are Generating a code (Operation= GenerateAuthorizationCode), or at the time you are exchanging the code for a token (Operation = GenerateAccessToken) ? The policy checks the redirect uri in both cases.

Can you give more specifics to your problem? Surely you are not using "myurl://" as the redirection URI. There will be a path involved. And so on. Please share what you can.

Edit

Hi, I understand you are still looking for help with this question.

I have asked for more information, I think i'm still waiting on that.

In the interim, I have tested exactly the scenario you describe:

• An OAuthV2 token dispensary that issues tokens for authorization_code grant type.
• An application (client) with a redirect URI that uses a non-http/s URI scheme

I just tried this and it works just fine.

Here is a screencast that I recorded showing what I did.

All of the code I used for this is available in this github repo.

[#3]

Joe Zwack's answer below was actually answering your questions. We are still looking for help on this question. Thanks.

[#4]

Hi @Dino urls like "Myapp://" are commonly used for redirecting to an application on a mobile device.

Let's say I wanted to use a mobile app as my redirect, and it has a common name of "myapp://". That is where the flow is erroring out for us.

It's "Authorization_code" grant type, and the error appears on the redirect step, when generating the auth code.

[DChiesa]

OK. Do you work with Jaye? I understand about custom URI schemes, and how they can be used in authorization code grants. I'm clear on when the error occurs.

Have you registered the callback URL in the Developer app? A Developer app that uses authz code needs to have a callback URL registered, and it needs to match the one you use at runtime.

[#6]

I should have clarified for you. The redirect works with a standard http-formatted URL, just not with the aforementioned format. So I believe we have the URL registered in the dev app correctly. The problem only occurs if I modify the url format, so I believe that is what's triggering the problem.

[DChiesa]

The redirect works with a standard http-formatted URL, just not with the aforementioned format. So I believe we have the URL registered in the dev app correctly

Yes, mmmm, well I'm not clear then. Usually you must register a URL, and the urL used at runtime must match what is registered for the app. Therefore....

configured URL	URL used at runtime	result
https://foo/bar	https://foo/bar	success!
https://foo/bar	myapp://blah/bam	failure - invalid URI specified (scheme mismatch)
myapp://blah/bam	https://foo/bar	failure - invalid URI specified (scheme mismatch)
https://foo/bar	http://foo/bar	failure - invalid URI specified (https != http)
myapp://blah/bam	myapp://foo/bar	failure - invalid URI specified (path mismatch)
myapp://blah/bam	myapp://blah/bam	success!

At least this is what I expect to occur.

This is why I am asking, "what URL have you registered?" and "what URL (specifically) are you using at runtime?"

[#8]

And what about a callback URL which contains query parameters? Like for example "http://foo/bar?test=value" ? Could you please check it as well?

Currently, I'm having some issues with such URLs when using the Volos library and I'm not sure if this is a problem of the policy itself or the library.