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
Solved! Go to Solution.
There are mainly 2 ways of doing this with mobile apps:
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.
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
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
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
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...
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
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
There are mainly 2 ways of doing this with mobile apps:
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.
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
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.