Oauth2 redirect url dynamic address

[#1]

Dear all,

it may be silly question but i am stucked with following doubt:

mobile apps have dynamic address because installed on smartphone. So what should the callbackURL in Apigee Edge? Should i leave that blank and only pass it in the OAuth2 3-legged flow during token creation process? If so, apigee says that this case should only be used for trusted apps:

http://docs.apigee.com/api-services/content/oauthv2-policy

Please advice.

thanks lot,

Antonio

[gnanasekaran]

redirect_url cannot be dynamic. You need to provide a redirect_url, while registering, that [only] your application will have access to.

Oauth server [Edge in this case], will redirect the access_token to the redirect_url you have provided.

This is implicit grant - which by itself is not very secure -- but having dynamic redirect_urls is dangerous

[#3]

Hi thanks for your time.

I think you may have mis-understood my question.

How do you set the CallbackURL (not redirect_url!) in Edge for a mobile app using Code Grant flow?

What CallbackURL the thousand or millions of mobile app instance are listening on? and they have to be all different...

thanks lot,

Antonio

[gnanasekaran]

i think callbackurl and redirect_url are one and the same - so if you are using authorization_code grant, then you will need a server [a server counterpart for your mobile app] to handle auth code and get token.

So the callback/redirect would be your server url and not millions of mobile app instances.

So Edge would callback your server, so does the millions of mobile app instances [interacting with your sever]

http://docs.apigee.com/api-services/content/oauth-v2-policy-authorization-code-grant-type

[#5]

well but exactly at this link

http://docs.apigee.com/api-services/content/oauth-v2-policy-authorization-code-grant-type

the flow shows that the client app (i.e. the mobile app and not a server) is listening on the callbackURL...

[gnanasekaran]

sorry if it caused confusion - it is supposed to mean the server component of the mobile/client app

so the idea of the redirect/callback is to guarantee that the oauth server is delivering the code/token to the intended client_app - so the URL is negotiated at the application registration time.

There is no way to make this dynamic - because if you do - then there is no way to ensure code/token is delivered to the intended app

[#7]

@Mukundha Madhavan

Ok that is my point! How does each (thousands) mobile app can have its own/unique inside server component and be registered in Edge. Should i register thousands of callbackURL in Edge?

thanks,

Antonio

[ozanseymen · Accepted solution]

Hi @antonio bruno

There are mainly 2 ways of doing this with mobile apps:

1. Use temporary credentials concept where server generates a code and asks the user to type it in the app. App will then go to the server with this code and get tokens. This is mostly done when app cannot listen on external requests coming in.
2. You register a "custom URI scheme" on iOS or define an "Intent" on Android. Both will be used by the mobile browser to start your app. You register that URI in Apigee during application on-boarding. When OAuth handshake starts, you will start the browser and point it to the authorization endpoint. User will interact with the browser. Server will then respond with a 302 redirect to mobile browser with your custom URI scheme or Intent target in Location header. Mobile browser will then wake your app to handle the rest.

There are a lot of content, tutorials, tips and tricks on both approaches on the net - including heated discussions on _very custom_ URI schemes and global namespacing. I'd recommend you read those before implementing this.

[#9]

Thanks @oseymen@apigee.com

So if i understand in case:

1. there is no callbackURL so there is no chance to be attacked with phishing on the callbackURL, right? but clearly the user has one manual step to do.

2. this looks completely browser driven..

thanks lot,

Antonio

[ozanseymen]

For item 1, there is no chance of phishing as user is manually opening up "your app" and typing in the code. Item 2 is completely browser driven and works just like normal oauth callback.