We are considering securing a REST interface so that only a list of known client applications can access it, having similar requirements as: How to make sure API requests come from our mobile (ios/android) app?
To avoid reinventing the wheel we are considering using a '0-legged' OAuth implementation, where the clients request resources signing the request only with the consumer key and consumer secret (I'm using the term 0-legged as per this great blog post: http://www.bfcamara.com/post/34158128493/oauth-2-legged-vs-0-legged-uservoice-api-as-an).
I have been researching if any iOS APIs provide support for this kind of OAuth usage, but there seems to be a lot of confusion with the terminology. Are you guys aware of any iOS OAuth API that can be used in a '0-legged' fashion? Should I do my research using a different terminology?
Many thanks,
Gustavo
Related
Our existing customer base is in peoplesoft and we are developing lot of mobile applications. Hence, we would like to use oauth 2.0 for authentication and authorization, but i cannot find any way to integrate the two.
Does PS implement OAuth? If they don't then you'll be out of luck. A quick search indicates they support SAML for SSO (on their web sites). You will probably have to describe a little bit more what you are doing, and why you think OAuth is the way to go.
Note that being mobile doesn't necessarily mean you have to implement OAuth.
This is a very late answer, but as of PeopleTools 8.58, PeopleSoft applications support OAuth2 for REST services. The caveat is that only Oracle IDCS is able to be used as an authorization server. There may be a plan in the future to support other authorization servers.
Cf. https://blogs.oracle.com/peopletools/what-peoplesoft-is-doing-with-oauth2-in-858 and https://support.oracle.com/knowledge/PeopleSoft%20Enterprise/2621182_1.html for more information.
I have been tasked with creating a Web API for our mobile application and future 3rd parties to use in order to access our data, etc.
That alone is simple enough, but then I need to secure it. Initially, after reading about OAuth and doing some research, I decided to go the home grown token based route utilizing best practices found online for security. My prototype worked wonderfully but unfortunately the company wants to use OAuth since it's a recognizable standard and considered marketable to our clients.
Soooo, after banging my head against multiple walls the past few days I am curious if anyone has an implementation using OAuth as a service provider and then an ASP.NET Web API client as consumer.
The workflow envisioned is that the mobile application would hit the API which in turn would expect token(s) issued from our self-hosted OAuth service provider. I've yet to find any comprehensive documentation or examples online about this. So far everything I've seen is very piecemeal and therefore incredibly frustrating trying to implement anything.
Well - there is the OAuth spec of course (since you seem to like to handcraft things ;)) https://www.rfc-editor.org/rfc/rfc6749 and the corresponding threat model - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-threatmodel-08
Our OAuth2 authZ server / sec library has an implementation as well - I compiled some docs here: https://github.com/thinktecture/Thinktecture.IdentityServer.v2/wiki
<context> I got frustrated yesterday and posted a flame question which was quickly (and appropriately) closed and deleted by my fellow SO cohorts. Yahoo! turned off its standard PlaceFinder API endpoint and replaced it with a paid service. That's not the part that frustrated me though, it was mostly the fact that they changed their access model to require OAuth. One of the closers of my question commented something to the effect of:
you didn't keep an eye on deprecations of API's you depend on, OAuth
is better for users, suck it up.
While I could argue the facts of my API-watching by again blaming Yahoo for having broken links when they first announced the API deprecation back in October / November of last year, I think it would be more productive to try and turn this into an intelligent question. </context>
I have used OAuth. I like OAuth. Not only does it let you authenticate users and simplify sign ons to your application, it lets you ask for authorization to access that user's data from other apps. But PlaceFinder data is not private user data. It is for known place names and global identifiers (WOE ID's) that can be shared by everyone.
This morning I gave Yahoo! BOSS GEO my credit card information and started spiking up an OAuth API consumer to test it out. I started with DotNetOpenAuth, which I have used in the past. I read through Yahoo!'s OAuth guide and created a DotNetOpenAuth.OAuth.ServiceProviderDescription instance with all of Yahoo!'s OAuth 6.1, 6.2, and 6.3 endpoint URL's. I then went about trying to figure out how to use DotNetOpenAuth.OAuth.WebConsumer to hit the PlaceFinder API and start giving money to Yahoo!.
But it didn't work. I had to overcome a lot of cognitive dissonance, and in the end, either a limitation of the popular and widely-used DotNetOpenAuth library itself or a possible misuse of OAuth. When I finally realized that the BOSS documentation was separate from the BOSS GEO documentation, and found a C# code sample that worked to consume Yahoo!'s PlaceFinder API, I discovered where all of that dissonance was coming from.
Yahoo!'s PlaceFinder API, while it uses OAuth, does not require an Access Token to get at the API's endpoints or data. When you send a PlaceFinder request, you send all of your app's information (consumer key and secret), along with the timestamp, nonce, and signature to the PlaceFinder endpoint itself. When I used OAuth in the past, these elements were sent to the 6.1 endpoint to obtain a request token. You could then use that to authenticate / authorize the user (6.2) and obtain an Access Token (6.3) to make further requests.
Here's the limitation in DotNetOpenAuth that I can't overcome so far, so if I'm being ignorant and doing it wrong here please tell me. In the sample C# code on Yahoo!'s site, they are not using DotNetOpenAuth. Instead they have an OAuthBase class that you can use to generate a nonce, timestamp, and signature. But they send empty strings for the access token and secret. I tried doing this with DotNetOpenAuth, but it won't let you construct any requests with a null or empty access token.
So the question: Is this an inappropriate use of the OAuth standard? If not, is there a limitation in the DotNetOpenAuth library that makes it impossible to send unauthorized requests to endpoints other than for a RequestToken (6.1)? If the answer to both of these is no, how could you use DotNetOpenAuth to request PlaceFinder data without having to send an access token or secret?
This is a great question. I think oAuth provides BOSS developers with two benefits
Since you sign up for BOSS once and can then use that key for multiple services, the BOSS team wanted to have the flexibility to offer more services that needed tokens in the future. Starting with oAuth right from the get go allowed that flexibility.
The team wanted to ensure that keys are not sniffed out during network communication. Since requests are signed and actual keys are not passed, we can ensure that no sniffing happens.
Regarding your question on DotNetOpenAuth, I recommend asking on the BOSS Y! group (http://tech.groups.yahoo.com/group/ysearchboss/) since we have a number of folks who have written in C#, VB.Net who can advise you. In fact it is well known that the VB.Net oAuth library (http://oauth.googlecode.com/svn/code/vbnet/oAuth.vb) has some issues with it.
There's two types of oAth that yahoo uses. One requires a key, one doesn't. You probably want the one that doesn't for general API use. Just add the secure protocol http:// -> https:// and then place /public/ in an appropriate spot of the old url like
https://somePartOfURL/public/otherPartOfURL
I need to develop an API to be the core of a web APP.
My initial idea was making a REST API that would treat all the request and then create some clients for web, mobile and desktop.
My question is, How should I manage the authentication for this situation?
I thought about using a token that would be passed with all requests to the REST API.
Im my case, I would not like to have something like OAuth because the ecosystem will not have multiple apps like Facebook/Twitter does.
NOTE: I must have the API separated from the client for web.
In more details, I would request POST /users/auth passing their password and username, and receive an auth token.
Is it a good approach or there is something better?
Agree that Devise is great for the auth in the application. For the API level, 3scale could help a lot (http://www.3scale.net) - it takes care of rate limits, keys, oauth secret distribution, analytics, developer portal and other stuff. There's a ruby plugin to get started here: https://github.com/3scale/3scale_ws_api_for_ruby.
Devise is a fantastic gem that handles authentication in rails apps. It also provides token based authentication. You can find many resources on the web (for example here) explainig how to use it. No doubt it will fit for your situation.
We are currently using an outdated screen scraper gem to import contacts from gmail/yahoo/etc. I want to update this to use the new OAuth based APIs so users don't have to enter their credentials on our site. I'm really intrigued by the work Plaxo is doing with Portable Contacts which Google also supports. It feels like that is a good direction for read-only access, and it is still backed by OAuth.
Are there any compelling reasons to just go with the standard OAuth API for these providers instead of going the Portable Contacts route? I'd like to know if there are strong reasons to avoid it. I'll still be using straight OAuth for the ones that don't support PC so it's not a question of development time, more one of support and confidence in the new approach.
The idea is that each OAuth implementation will be slightly different where as each Portable Contacts implementation will be the same. It's kind of like a REST API (OAuth) vs. a SOAP API (Portable Contacts --but with the same overhead as OAuth).
So you should theoretically be able to make one Portable Contacts Reader and hook it to any provider who supports it with no additional work.
In reality for now, you'll probably need to work with both Portable Contacts and OAuth-non-portable endpoints. (With most OAuth-non-portable providers hopefully moving towards Portable Contacts).
OAuth Core doesn't define either discovery (leading users to the OAuth URL which will let them authorize the resource to the consumer) or representation (informing the consumer about what authorization the token will provide). Without a spec such as Portable Contacts, these need to agreed upon ad-hoc by the consumer and provider (with discovery probably being simplified to a well-known URL). So Portable Contacts is just answering those questions once for each provider which uses them. You'll need to work out the ad-hoc answers if you want to support providers which don't, but you'll be using the same OAuth Core implementation for all of them anyway.
Portable Contacts itself builds on the OAuth Discovery spec, which seems to be expired without a replacement, unfortunately.