I want to access few social networks such as Instagram, Facebook, Twitter in my iOS app. I need to get user info, their friends etc. All this social network use OAuth 2.0 to allow my app get some data. As I understand, I need to have my own server to use its URL as redirect_uri. So the question is How to create this server?
I expected there are some tutorials and ready to use samples, but I didn't find any useful links.
you don't need to have a server for redirection.
OAuth 2.0 define a special redirect_uri for installed apps.
For example, Google OAuth define two special redirect uri,
urn:ietf:wg:oauth:2.0:oob and http://localhost
The first one results in an authorization code in the title of the page, and the second one results in the authorization code sent to a http://localhost address as part of the query string.
you can get more information from
https://developers.google.com/accounts/docs/OAuth2InstalledApp
and a reference for you
https://github.com/tikitikipoo/ios_oauth_twitter_and_facebook
Related
New to Oauth and had a general question. Is there a way to restrict who can log into your site with Oauth 2? Similar to AD groups or something so I could control who I want to be able to log in based on group or user name? I would like people to use google or facebook but only let certain people actually log in.
You can filter users in a code that handles the redirect_uri. If you use the Auth code grant, that will be some backend code and if you use the Implicit flow, it will be a code in a browser application. But the JavaScript security restrictions should have their equivalent somewhere at the backend too, since the JavaScript code can be altered by the browser user.
To be able to do that (to have info about an authenticated user), you should either request an ID token or an access token with a scope that authorizes you to get user info at the /userinfo endpoint.
I'm integrating Dropbox support in my application, and to get an access token to a user's account I use their OAuth2 flow. After the user has granted the application access I need the user to be redirected to the same URL it came from. The problem is that a user may come from any of a number of subdomains, and I don't have full control over these subdomains, which means I can't add them all to the redirect URL list in my Dropbox app settings.
I thought I'd solve this by having a general redirect URL under the www subdomain, which in turn would redirect to the correct URL. However, there doesn't seem to be any way to send custom data that Dropbox will include in the redirect URL. I've expermiented with YouTube's OAuth2 API and they allow you to send custom data in a state query parameter, which it will include when redirecting back. But this does not seem to be allowed for Dropbox. Does anyone know whether there is any way to do this?
Thanks
Dropbox supports the state parameter (up to 500 bytes, see the docs for /1/oauth2/authorize), and you can set arbitrary state in the Python SDK using DropboxOAuth2Flow.start.
When you complete the OAuth flow and call DropboxOAuth2Flow.finish, the state you passed in will be returned as the third member of the tuple.
If Dropbox doesn't honor the state parameter (and violates the spec doing so) the only alternative is to make sure the custom domains redirect to the general domain as well before kicking off authentication towards Dropbox, and then store the custom URL in a cookie that resides on the same general domain as the redirect URL. You can then pickup the state/custom URL from the cookie on return from Dropbox.
I have implemented Google oAuth on the site (example.com). Everything works fine except auth from subdomains on my site(I have a thousands of subdomains). When the user tries to authorize via subdomain, for example
fr.example.com
product1.example.com
product2.de.example.com
I receive an error from Google -
The redirect URI in the request did not match a registered redirect URI
How it could be solved ?
The other answers have already clarified that the cause of the troubles is that Google's OpenAuth doesn't support wild card sub domains. However, what you're asking is how can it be solved? Well, you have two choices, according to this email thread:
Provide a single OAuth2 handling endpoint for all subdomains. That is, you'd have a main domain and endpoint, via which you do authentication also for the sub domains. When done authenticating, you redirect back to the sub domain. There's supposedly an OpenAuth state parameter, in which you can encode the sub domain name. This is what I did, here's the code: https://github.com/debiki/debiki-server/blob/master/app/controllers/LoginWithOpenAuthController.scala
You can have each sub domain register independently with Google.
Which option you'll choose depends on which brand the Google users are asked to approve. The main domain, or a sub domain?
That's because Google's OAuth does not support wildcard subdomain matching. You can refer to more documentation here
The redirect URI must exactly match one of the values listed for this project in the Google Developers Console (including the http or https scheme, case, and trailing '/'). So it will not support sub domains if you don't add them in Developers Console.
That's because Google's OAuth does not support wildcard sub-domain matching .You can redirect the one static page of all sub-domain and after authenticate or get access token of OAuth then you return on your sub-domain page with access token.
In the Authorized JavaScript origins field, enter the origin for your app. You can enter multiple origins to allow for your app to run on different protocols, domains, or subdomains. You cannot use wildcards. In the example below, the second URL could be a production URL.
http://localhost:8080 or
https://myproductionurl.example.com
https://developers.google.com/identity/sign-in/web/server-side-flow
I'm developing an iOS app that uses the Magento REST API, I'm following the documentation provided by Magento for the OAuth authentication (http://www.magentocommerce.com/api/rest/authentication/oauth_authentication.html)
I use the initiate endpoint to get the request token but then when I want to authorize this token I need to use the "authorize" endpoint and there I get redirected to a URL where I have to provide customer credentials to authorize the request token. This is not the behaviour that I was expecting since the user would be already logged in using the app's login (not implemented yet). Is there a way of making this "authorization" step transparent for the user? Like calling some service passing it the user's credentials provided in the login screen of my app?
If there is no way I'll use the Magento's SOAP API
I did that too really really painful Magento use OAuth1.x, basically you've got three options:
Do it yourself
Use some oAuth consumer lib, you can find them on github
Use MKNetworkKit with this add-on
I used the 3rd because oaf MKNetworkKit, and anyway there was still a lot of work to do, if you want to hide some passages injecting js.
i wonder how do desktop apps without any domain names use oauth? or is it not supposed to be used this way? if so what do i use? say for tumblr they have an authentication api so i will have to put the username and password in the url/query string?
i am thinking of using WPF/Adobe AIR. how does something like tweetdeck work?
I've been puzzled by the same question about lack of domain or app url, but it turns out redirection is not the only possible way to complete OAuth authentication process.
I.e., when webapp requests access it provides callback url: the one user will be redirected to when process is completed. That's how webapp know that everything's done.
But you can't redirect to application on user's machine. Thus, there's another way: upon successful authentication server presents special code to the user. Then user copies this code and provides it to application.
You can see both ways described in specification draft.
Also, here's an example of this authentication flow with twitter.
It looks like it may be possible, see googles docs on the subject:
https://developers.google.com/identity/protocols/oauth2/native-app
For a desktop app where a user needs to authenticate himself, you will usually want to use the Authorization code flow.
The approach goes roughly like this:
setup a temporary webserver that listens on the loopback interface
present the login page to the user (either in an embedded browser control or an external browser), with the URL of your temporary webserver as redirect_url
upon successful login, the user will be redirected to your temporary webserver and you can obtain the access code from the code query parameter
Using the access code, you can obtain a token and start making requests using it
Shutdown the temporary webserver
Please note that you will have to allow localhost as redirect URL in your identity provider, in ordrer for this approach to work.
For further details, please take a look at these sample apps from Google.
You should start by reading about getting started with OAuth. Eventually, even a desktop application will open a browser window to authenticate the user - TweetDeck and other Twitter clients do this, as you've probably noticed.
Tumblr, in your example, doesn't use OAuth but rather basic authentication that is being performed via simple HTTP web requests.
Twitter doesn't want users entering their credentials into your application. So at some point the desktop app will need to open a browser window through which Twitter can authenticate their users and return an access token representing the user. From that point the desktop app can use the access token to represent the user in all subsequent API calls to Twitter.
In a desktop environment you have another way to get the token, the browser open url itself.
the OAuth2 server will redirect the users browser to the Redirect URL with the token as a query parameter, so if you control the browser used, you can read the the token directly from the url that the user was redirected to.
Graphical libraries like GKT+ have integrated options to create mini browsers that the user can use to authenticate, and it automatically return the token to the app, but other options are possible, like reading Firefox url for example.