So far, I have my dotnetopenauth Provider and Relying installed and working on a server. Great tool, however, the only 2.0 relying party site I can do an unsolicited assertion into is my own dotnetopenid relying party site. Can someone give me an example of a 2.0 relying party site that will except a unsolicited assertion from dotnetopenauth OP.
I have tried many sites, Plaxo being one of them, there does not seem to be a list of Open ID 2.0 relying party sites. Its hard to believe everyone is still on 1.1
Do you know of any who has done it correctly, is there a link in the world that I can test with besides my own. I am working on a large scale project with my company. I have used your op server and integrated into 2 factor authentication with a successful assertion into my RP. But I would like a site that this process work's with outside of my own to prove your programs worth.
I can't prove it without your help, can you help me find one site this will work with. I understand your design, fantastic by the way, but I need to be able to use it in a manner that will prove worth to our company. I am a large scale senior developer, however, I am flying solo on this project.
Anything you or your team could do would be great.
Most RPs are (presumably and hopefully) using OpenID 2.0. However, implementing everything correctly such that unsolicited assertions work is something that most RPs in my experience don't get right. Even a DotNetOpenAuth RP must still manually wire up their realm discovery page with the appropriate XRDS document to work correctly.
So you're probably doing it right... and most everyone else is doing it wrong. That said, the OpenID 2.0 spec doesn't actually document how unsolicited assertions should be sent. That's sort of left out. So DotNetOpenAuth does RP discovery to figure out where to send the unsolicited assertion to -- which if the RP holds true to the spec should just work but because most things appear to work with a broken RP discovery doc, and most folks don't test against unsolicited assertions, it goes unfixed in their sites.
Related
I'm trying to develop an open source solution which will be deployed on Raspberry Pi's or similar SBCs. The RPi part is only relevant insofar as it means all the code and app resources need to be publicly available.
The solution needs to read Twitter statuses, as close to real time as possible, and with as little interference from third parties as possible. I found Twitter's Streaming API, which is blazingly fast, and would be perfect for my application – except it requires OAuth. And as far as I can tell, the OAuth mechanism isn't well suited for deployment on users' machines, since it relies on a secret key which belongs to the application owner (the consumer secret).
I couldn't find any easy way around this – the only solutions I could think of are either handling request signing on a central server, or asking each user to create their own Twitter app account. And I find both solutions terribly distasteful.
Do you see any elegant way out?
It turns out this is indeed not currently feasible cleanly with any of Twitter's public APIs; not now, and not in the foreseeable future. Refreshingly, for once we do have proof for a negative: I also asked this on Twitter's own forum, and I was lucky enough to have my question kindly answered by Andy Piper, Global Lead Developer Advocate at Twitter. There you go.
Your app can open a web browser with Twitter's application authentication webpage loaded. When the user enters their credentials Twitter will return a code which they can copy/paste into your app. It's not particularly elegant. Here is a Python example of the workflow: https://github.com/geduldig/TwitterAPI/blob/master/examples/oauth_test.py
I have spent the past three days researching OAuth 2.0 and I understood how OAuth can be used to interact with a service provided by a heavy weight such as Google or Facebook. However, I'm struggling to see how someone without a team of tech wizards (aka Me) goes about protecting their API with the protocol.
I have a number of questions and was wondering if someone with some experience can help me.
Here goes nothing...
Is there a clear cut leader in terms of an OAuth Authorization Server implementation (Java)? If yes, is there any good resource out there to teach me how to use it?
Its my understanding that I would need to either build an authorization server or leverage a library to dish out client secrets/tokens.
Should I even be thinking about a library or should I be building my own implementation?
Is OAuth still relevant? From what I can see, it seems like the hype around the technology has leveled off or diminished since 2010. I also saw an article where the spec lead disassociated himself from the protocol.
I appreciate any advice or help, I can't find many resources on this topic that address it clearly (tons of Powerpoints, no code). There seems to be a bunch of talk about how it works, yet no book or article can give a solid tutorial. The documentation for the providers I have found is also very spotty at best. I'm just really starting to question whether this is a legitimate undertaking for someone looking to protect their own simple API. Thanks ahead of time.
Take a look at the Libraries on the OpenID Connect developer pages here: http://openid.net/developers/libraries/
I don't think there's a clear cut leading Java implementation yet
I would not recommend implementing the Authorization Server part on your own, that is the complex part and details matter because this is about security; the client part is easier and should be possible to build even without a library
OAuth is very relevant as it is the only standard out there for securing REST APIs; the hype is over, and now it is common technology; just take a look at all big vendors/SaaS out there, they all use it (starting with Google, Microsoft, Facebook, Twitter etc.)
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
I'm starting a new system creating using .NET MVC - which is a relatively large scale business management platform. There's some indication that we'll open the platform to public once it is released and pass the market test.
We will be using ExtJs for the front-end which leads us to implement most data mining work return in JSON format - this makes me think whether I should learn the OAuth right now and try to embed the OAuth concept right from the beginning?
Basically the platform we want to create will initially fully implemented internally with a widget system; our boss is thinking to learn from Twitter to build just a core database and spread out all different features into other modules that can be integrated into the platform. To secure that in the beginning I proposed intranet implementation which is safer without much authentication required; however they think it will be once-for-all efforts if we can get a good implementation like OAuth into the platform as we start? (We are team of 6 and none of us know much about OAuth in fact!)
I don't know much about OAuth, so if it's worth to implement at the beginning of our system, I'll have to take a look and have my vote next week for OAuth in our meeting. This may effect how we gonna implement the whole web service thing, so may I ask anyone who's done large-scale web service /application before give some thoughts and advice for me?
Thanks.
OAuth 1 is nice if you want to use HTTP connections. If you can simply enforce HTTPS connections for all users, you might want to use OAuth 2, which is hardly more than a shared token between the client and server that's sent for each single request, plus a pre-defined way to get permission from the user via a web interface.
If you have to accept plain HTTP as well, OAuth 1 is really nice. It protects against replay attacks, packet injection or modification, uses a shared secret instead of shared token, etc. It is, however, a bit harder to implement than OAuth 2.
OAuth 2 is mostly about how to exchange username/password combinations for an access token, while OAuth 1 is mostly about how make semi-secure requests to a server over an unencrypted connection. If you don't need any of that, don't use OAuth. In many cases, Basic HTTP Authentication via HTTPS will do just fine.
OAuth is a standard for authentication and authorization. You can read about it in many places and learn; Generally the standard lets a client register in the authentication server, and then whenever this client attempts to access a protected resource, he is directed to the auth-server to get a token (first he gets a code, then he exchanges it with a token). But this is only generally, there are tons of details and options here...
Basically, one needs a good reason to use oAuth. If a simpler authentication mechanism is good for you - go for it.
I'm trying to secure my MVC4 Web Api. Actually, I just really need an identity provider with some light security. My service is similar to twitter, from a security standpoint, there's not a lot of private data, but the service does need to know the userid for the caller.
It's also important to know that the web service will only be consumed by mobile devices right now, although a website may accompany it at some future point.
S.O. and the internet have led me to Thinktecture.IdentityModel, but man it seems complex and I can find exactly zero documentation or samples. I also haven't yet had a pleasant experience with claims-based authentication. I don't have a claims server, token provider, or anything like that, and it seems like you would need that to use this method. This all seems far to heavy for my situation.
I've also read about people implementing their own HMAC solution (https://github.com/cuongle/WebAPI.Hmac) or using OAuth (https://github.com/maksymilian-majer/DevDefined.OAuth) but these also seem a bit complex (I've read that OAuth without the helper class is enough to make the best developers cry, and I'm not the best). Janrain looks like it might work, but it looks like you have to pay for more than 2,500 authenticated users per year ...
What is the best way to implement a simple identity provider and security for Web Api?
Thanks!
I have attempted to answer a similar question to this before Create an OAuth 2.0 service provider using DotNetOpenAuth where I highlighted the Thinkecture Identity Server. The Setup instructions not too difficult (IMHO) The installation video is here and should help a lot.
I have updated my older answer with this too but there is also a fairly lightweight O-Auth 2.0 implementation example here Sample code here http://code.google.com/p/codesmith/downloads/detail?name=OAuth2.zip&can=2&q=#makechanges
Have you also read this well articulated question here Authenticating requests from mobile (iPhone) app to ASP.Net Web API (Feedback requested on my design)
Well, security is hard :)
As for Thinktecture.IdentityModel -- this is a token processing library (among other things) that you'd use in your WebAPI application. You'd use this so you don't need to do the logic to accept tokens (basic auth, SAML, SWT, JWT). Claims are just a side-effect.
If you're looking for an identity provider, then the sister open source project Thinktecture.IdentityServer is in beta for version 2. It's an identity provider that supports a custom database and issues tokens. The project URL is:
http://thinktecture.github.com/Thinktecture.IdentityServer.v2/
In response to the problem of finding example code as documentation, consider the samples folder in the Thinktecture github repo: https://github.com/thinktecture/Thinktecture.IdentityModel.45/tree/master/Samples
(Why do you need more reputation to comment on SO than to answer?)