I'm just brainstorming, and don't really know much about these technologies yet. What I want to do is provide an easy and secure for users to prove who they are across multiple web sites, and I want to provide a way for web sites to share certain information with each other (if the user gives them permission). After a little reading, it seems like OpenID and OAuth would be the best way to solve this problem (right?).
After searching, I've found two interesting projects. One is "Step2" which only has Java libraries (not a problem for me, but other, partner websites might not be coded in Java), and looks like it has been abandoned. Another is "OpenID Connect," which doesn't look like it's even been started.
So, I've guess I've got three questions. Is linking OpenID and OAuth what I should be doing? Is there a OpenID+OAuth project that has a lot of support? If not, would it be easy to integrate the two myself?
OpenID is interesting in cases like Stack Overflow where you want to let people log in with external credentials but not with the intent of exchanging data with that external site.
But I don't think you need OpenID for the scenario described... by putting users through the OAuth flow, users are effectively "proving who they are across multiple web sites" as part of the authorization process.
Describe OpenID and OAuth, how works OAuth and what does OAuth.
DotNetOpenAuth is an open source library that supports OpenID, OAuth and
support for your site visitors to login with their OpenIDs.
Document describes OAuth authorization process as well as how to work with OAuth tokens.
Also gives an overview that How to implement Google using OAuth for our web application's.
Related
At work we have a system set up running a ThinkTecture IndentityServer SSO provider which currently provides authentication for several .NET and ColdFusion sites. I am currently working on a new site we are supporting in Ruby on Rails and am having difficulty figuring out how to connect it to the SSO. (I'm pretty new to rails, but a long time developer in CF and .NET)
I've looked at the omniauth-oauth2 and oauth2 gems but it seems there are important parts missing from the documentation and explanations I can find. There is a ton of info if I wanted to authenticate using Twitter, Facebook or something similar, but I can't find anything that just addresses the client side for any generic OAuth2 provider.
I'm just looking for someone to point me in the right direction to find information on how I can do this. I don't care if it's specific to IdentityServer or just generic regardless of the provider. Thanks for the help.
Update: Just so you know, I would prefer to use OAuth2 for this connection, but I am not opposed to using any of the other ways that IdentityServer provides, including ADFS, WSFed or Simple HTTP. I can't use OpenID, though, because these accounts are specific to our system and can't be used for other systems.
You really need an open id connect library.
http://openid.net/developers/libraries/
It turns out this is pretty easy, overall. The difficulty is that there is no straight answer to the question. How you connect to IdentityServer entirely depends upon how IdentityServer is set up.
I'm not going to post my exact code, as this will not help anyone who doesn't have IdentityServer set up exactly the same way we do, and as I don't have access to the IdentityServer, I can't say exactly how that is. I will explain the overall solution, though.
The only gem needed for this is JWT
Get key codes from IdentityServer admin (client id, secret key, sign key)
Build login URL according to configuration of IdentityServer
Redirect user to login path generated in the last step
Receive token back from IdentityServer
Decode and verify using the JWT.decode function
From there you just have a JSON string with your data.
I am trying to build an application that will use data from multiple social services. The user will need to authorize their accounts to be accessed across these multiple services (e.g. facebook, twitter, foursquare) using oauth.
I don't really need the users to login with these accounts, really it is just allowing their data from the api to be pulled.
I know I need to use oauth, but I am having trouble finding a basic example of how to do this type of thing (a lot of examples exist for logging in with oauth).
I have been trying the python-oath2 library.
Does anyone have any recommendation for a good tutorial or example of doing this type of thing in python, and if possible django.
Thanks.
Why reinvent the wheel? There is a plethora of reusable applications that have this implemented. You can find a comparison here: http://djangopackages.com/grids/g/authentication/
Why not give rauth a try? We use this in production for this exact purpose. Although you don't need to require the user to login with your app via the provider, you're going to redirect to the provider, where they'll be asked to authenticate your application. Assuming they accept (or even if they don't), they'll be redirected back to your application, i.e. via the redirect_uri or oauth_callback, there you'll ensure they authorized your app and then proceed with whatever housekeeping you need to do, e.g. saving some info about the user in your database. Try the examples and also pay particular attention to the Facebook example. Now the Facebook example is intended for authorization with the example web app, but the same pattern can be used for what you're trying to do. (You just won't be having them login in via Facebook, for instance. However, the flow can be and probably should be identical, sans database operations and template login lingo.)
I want to implement a new REST-based API on our infrastructure, and OAuth seems to be the way to go.
For our implementation, there will first just be server-to-server access, which will be completely unrestricted. I believe this is called two-legged authorization.
Later on, we'd like to allow the API to be consumed by the browser, which will turn our authorization into three-legged.
Is there a good starting point for implementing this? How can we fully authorize a server and down the road add restricted authorization per-user?
The OAuth specification is not really helpful in these scenarios, but I believe this implies we need to create a never-expiring session for the server-to-server access, and later on add normal sessions with limited access for user-only APIs.
I'm hoping to find starting points for more information, let me know!
Is OAuth for me? I'm only looking for a authenticated request system, and only the consumer and service provider exist in this scenario. The end-user does not come in to play!
Ya, OAuth is probably for you.
There are actually two OAuth specifications, the 3-legged version and the 2-legged version. The 3-legged version is the one that gets most of the attention, and it's not the one you want to use.
The good news is that the 2-legged version does exactly what you want, it allows an application to grant access to another via either a shared secret key (very similar to Amazon's Web Service model, you will use the HMAC-SHA1 signing method) or via a public/private key system (use signing method: RSA-SHA1). The bad news, is that it's not nearly as well supported yet as the 3-legged version yet, so you may have to do a bit more work than you otherwise might have to right now.
Basically, 2-legged OAuth just specifies a way to "sign" (compute a hash over) several fields which include the current date, a random number called "nonce," and the parameters of your request. This makes it very hard to impersonate requests to your web service.
OAuth is slowly but surely becoming an accepted standard for this kind of thing -- you'll be best off in the long run if you embrace it because people can then leverage the various libraries available for doing that.
It's more elaborate than you would initially want to get into - but the good news is that a lot of people have spent a lot of time on it so you know you haven't forgotten anything. A great example is that very recently Twitter found a gap in the OAuth security which the community is currently working on closing. If you'd invented your own system, you're having to figure out all this stuff on your own.
Good luck!
Remember to distinguish between authentication and authorization. In some places, I believe that the OP mixes the two.
For example, once a server authenticates someone, it usually explicitly or implicitly (using cookies) provides an authentication token so that subsequent requests are already authorized.
It is up to the server how long the credentials last. It is smart to plan that the credentials will time-out at some point. Just have the client server be prepared to re-authenticate itself whenever it receives the "authorization expired" error response.
You don't want to try to provide a "never-expiring" session since:
Everything expires at some point. For example, how will the client server be able to start accessing the application again if it loses power or is rebooted?
You're creating an inflexible system. They tend to break more often.
Since you know that you want to add additional types of logins in the future, instead of two types of logins (server clients and browser clients), make just one type of login now. The additional work for the client server will be to implement a "re-login as necessary" capability.
OAuth will end up being too difficult for our needs. I've decided to adopt Amazon S3's authentication scheme, simply because it fits our model better.
Thanks for helping out finding an answer though..
I will launch soo a new iPhone app and want to off-load the forums to my actual FogBugz On Demand account.
However, I discover that FOD have no facility to integrate Single sing-on. I use django and have the option to use open-id, but not know if exist a way to make this happend.
Obviously, I could hack a simple forums like the one on FogBugz in django or reuse one, but I just think that aintegrated forum with the bug tracking is the best thing.
Any idea?
FogBugz On Demand now natively includes some authentication methods other than the standard username/password authentication.
Setting up authentication with Google's OAuth is quite simple for companies using Google Apps for work email. Once an administrator enables OAuth following the instructions in this article on Fog Creek Software's help site, logging in is as simple as clicking the OAuth button on the login page. All of the users' settings are retained.
If you’re already managing the rest of your authentication through a SAML 2.0 provider, you can also use your identity provider for FogBugz login. Steps for configuring SSO can be found in this article. This requires a bit more configuration than OAuth, but will work for companies that don't use Google Apps for email.
Of course, if you have any questions about configuring SSO in FogBugz, you can always contact customer support at http://www.fogcreek.com/contact/.
From the FogBugz forum:
http://support.fogcreek.com/default.asp?fogbugz.4.102256.3
I believe this is you there also. The answer provided shouldn't be too difficult to implement.
I'm going to be developing a REST-ful Web Service for a new public website. The idea behind the web service is to have 3rd parties develop fully functional UIs for the business logic.
For security reasons, I'd like to avoid users having to give their passwords for our service to the 3rd party applications. (Perhaps this shouldn't be a big concern?) Instead, I'm looking to implement some sort of login system on our site that provides an auth token to the 3rd party app but keeps the actual password out of their hands.
This made me think that OpenID might be a potential solution here. It seems to me that it should work: the actual password is handled by the OpenID provider and so it doesn't rest with the 3rd party app. I think that the trouble would probably lie with the various passthroughs, but that should be manageable.
However, there's a surprising lack of Googleable info on this, so I'd like SO's opinion. Has anyone implemented a similar system before? Is it even possible? Is it worth the trouble?
I agree completely that what you want is OAuth; I say that having worked on both OAuth and OpenID systems. I've also been in your boat a few times, having to develop a REST web service api.
For a really good ideas on OAuth, and why it is what you want see these attached article:
These are must read, there are four parts read them all:
http://hueniverse.com/oauth/guide/
the RFC, read after reading above as it can be a little daunting for most:
http://oauth.net/core/1.0
And then finally maybe some code. I have a couple projects hosted that are using Java/Groovy to do OAuth. One is a plain old OAuth client, the other is a client for specific interactions with NetFlix.
http://www.blueleftistconstructor.com/projects/
If you are relatively inexperienced with REST (you haven't built a full scale web api yet) I would recommend that you buy (or better get your boss to) "RESTful Web Services" by Richardson & Ruby. It is an O'Reilly book. I can say that it is one of their better books to debut in the past few years.
It might also help to look at some RESTful OAuth based APIs. The NetFlix API is a perfect example: http://developer.netflix.com/docs
Good luck and happy coding!
So far, I've found 1 worthwhile link:
http://markmail.org/message/utf7js473zqv45hv
This conversation mentions something called "OpenID Exchange" which is right up my alley... but the included link is broken and there's not much solid information on Google for it.
Looks like OAuth might be the ticket: http://oauth.net/
We have been working on a project to integrate OpenID Authentication for SOAP web services. You can find our project at http://code.google.com/p/ws-sandhana/.
You can provide Single Sing On to your web services using OpenID authentication and you can enforce the trusted OpenID Providers and required attributes of the users by defining service security policies.
This is an open source implementation on Apache Rampart which is the security module for Apache Axis2 web service engine. You can find our blog at http://sandhana-project.blogspot.com/ for more information.