does dotnetopenauth allows or has the ability to run own identity server?
We are interested in building a id provider such as stack exchange, google, or fb.
As well as authentication, we are interested in allowing users to register and then using same creds, accessing corps any resource without login again and again.
what s the best place to start? any source code to research for such impl?
Yes, indeed it does!
Best place to start would be the samples included on GitHub.
OpenID Provider
This example will show you the basics for setting up an OpenID provider.
OAUTH
An example of protecting an API with OAUTH - including an example implementation of an Authorisation Server
Have a look, it's a deep dive but worth it if you are serious about being an ID provider - a decision which should not be taken lightly. If you need help then search/post back here on StackOverflow, post on the Google Groups or talk in the JabbR room
Related
Basically, I have a homework assignment which involves me creating a MVC app in Asp.Net (the standard version, not Core). I need to provide authentication using jwt, but i have to use a separate authentication server, so the token creation and validation are delegated to that server, and if a server like that already exists (perhaps a facebook or twitter authentication server using jwt), i should use it rather than create my own. I am not sure if there is a jwt authentication server which I could use, and I don't know what is the best way to handle jwt tokens, for example if i have a form that submits stuff to a controller action, how to place a jwt token in the request. Any help on this would be much appreciated!
As this is a homework assignment I'm going to try and provide a jumping off point rather than provide code samples or anything.
A JWT can be issued from another authority and used within your own application provided your application is set up to use that authority. For example, in house we use AWS Cognito to store our users, and in each of our web applications we specify that our JWT tokens are being issued by that Cognito user pool.
I've had a quick look around online for any issuers that may provide this service for free, and found the following blog post for Auth0 which boasts being able to support up to 7000 users for free (there may be hidden costs, I haven't looked into it fully)
The tutorial in the blog post seems to follow a .Net standard rather than a core implementation. Hopefully you find this useful and good luck with your assignment!
I hope someone can at least point me in the right direction here.
I have a need for Open Authentication in my business.
However it is not to use other services like facebook or google etc.
We have a membership database - a standard asp.net membership database (slightly modified with an additional table for profile information).
We also have multiple applications that our customers can use but require a log in, so we would like to use the membership database as an authentication source for these applications using open auth.
But i'm not sure where to start with it... everything i look at seems to point to using facebook or google etc as the source of authentication.
Where do I start with being the provider for open auth?
Any recommendations? Any advice for a newbie to open auth?
Our website is webforms, not mvc and runs on .net 4.0.
Thank you in advance!
Try to look at Thinktecture IdentityServer v2. It is an IAM that handles authentication. It is customizable. With little coding you can wire your membership database with it. See this page and IdentityServer wiki for more info.
You should start looking at the code from DotNetopenAuth, particularly the Samples. This is should give you enough to get started with OAuth and/or Open ID.
Particurlarly, look at this sample, as this uses OAuth2 to protect a web api, which can be used a starting point to something that can be used by clients in a very similar way to facebook or google logins.
Currently I'm developing some infrastructure and I've implemented my own RESTful authentication mechanism.
Now I've in mind that maybe I shouldn't go this way and use an industry standard so interoperability with my project could be trivial and easier to understand in terms of authentication and authorization.
After checking some articles googling everywhere and reading some Q&A here in Stackoverflow, I don't find how to be an OpenID provider - I'm not talking about authenticate users using Google, Windows Live, Facebook Connect and so, I want to develop an OpenID-enabled system so if some want to register into my services, they'll do in my own domain -.
Actually my question is: can anyone become an OpenID provider and is DotNetOpenAuth a library to develop this protocol in your own infrastructure?
Thank you.
Developing an OpenID Provider as a means of Single-Sign-On (SSO) within an organizations ring of web sites is a very valid scenario. DotNetOpenAuth comes with a pair of sample web sites (a Provider and a Relying Party) that demonstrate a single-sign-on relationship. They're called OpenIdWebRingSsoProvider and OpenIdWebRingSsoRelyingParty.
Please do not attempt to implement OpenID by yourself any more than you'd implement SSL by yourself. Getting OpenID security and interoperability just right takes a very long time and a deep level of domain knowledge. DotNetOpenAuth in particular gives you programmatic access to do just about anything you'd want to with OpenID, and since it's free, it's hard to go wrong.
Disclosure: I am a developer behind DotNetOpenAuth.
Actually my question is: can anyone become an OpenID provider and is DotNetOpenAuth a library to develop this protocol in your own infrastructure?
How to become an OpenID Provider
DotNetOpenAuth has some hiccups but all-in-all is a good tool to use it under .NET
if you're think you can do it, you can follow this:
Lastly, and most challenging, is implementing custom support for OpenID in your software and account management tools. While this approach of course affords the greatest degree of control over the user experience, it is also the most risky and only for developers experienced with web security. Start by reviewing the specs and documentation.
But my question would always be:
Why one more provider? Facebook, Google, MyOpenID, ... already have it, and with them, plenty of users have (even without them knowing) an OpenID login...
StackExchange is an OpenID provider since a while ago, but... there's so much users cross StackExchange platform. Are you developing such a big community so it will be reasonable to create and implement your own provider?
I see the answers are couple of years old. If you are looking for the latest solution to build an OpenID provider using Microsoft technology stack, IdentityServer is the open source option. One can use this and build an Open ID connect Identity provider.
Documentation on how to use and build : https://identityserver4.readthedocs.io/en/latest/
IdentityServer4 is an OpenID Connect and OAuth 2.0 framework for ASP.NET Core 2.
It enables the following features in your applications:
Authentication as a Service
Centralized login logic and workflow for all of your applications (web, native, mobile, services). IdentityServer is an officially certified implementation of OpenID Connect.
Single Sign-on / Sign-out
Single sign-on (and out) over multiple application types.
Access Control for APIs
Issue access tokens for APIs for various types of clients, e.g. server to server, web applications, SPAs and native/mobile apps.
Federation Gateway
Support for external identity providers like Azure Active Directory, Google, Facebook etc. This shields your applications from the details of how to connect to these external providers.
Focus on Customization
The most important part - many aspects of IdentityServer can be customized to fit your needs. Since IdentityServer is a framework and not a boxed product or a SaaS, you can write code to adapt the system the way it makes sense for your scenarios.
Mature Open Source
IdentityServer uses the permissive Apache 2 license that allows building commercial products on top of it. It is also part of the .NET Foundation which provides governance and legal backing.
I would like to use oAuth as a system to allow developers access to my API but not require them to pass through the login information.
There does not seem to be any good how-to's or blogs on this topic. Everything I have found is based on consuming an oAuth system such as Facebook or twitter. Wondering if anyone has any links to good instructions or libraries that could get me started. If there are no examples out there perhaps someone could consider writing one, the community really needs it.
Using OAuth to login is actually a side-effect, not the main goal of the protocol. The best place to start with providing an OAuth-protected API is the protocol specification and since this is a new service, you should take a look at OAuth 2.0 1. It is pretty much done and ready for deployment.
To implement OAuth 2.0 you will need to make a few important decisions about which features you are going to support and your scaling needs. There are also a lot of security considerations to go through. I would suggest you start with supporting the authorization code and implicit grant types.
I would look into DotNetOpenAuth. It should work for your needs, but I've only used it for the OpenID stuff.
I am in the processing of developing a web application which will integrate directly with a Google Calendar associated with a specific Google account. The account being accessed by the Google Data API is not likely to change, so I'm unsure what the most appropriate account authentication method is going to be.
I've reviewed the options avilable and it would seem that AuthSub and OAuth are inappropriate as I will not be logging users into their own account- only displaying and updating a fixed account. The other options available are ClientLogin and Gadgets authentication. Of all of them, ClientLogin seems the best fit, but the documentation states that it is intended for installed applications. While the web application I am developing is not specifically an installed application, it closely mirrors one in this scenario- which is why I think ClientLogin makes the most sense.
Which Google authentication option would be the best fit in this scenario?
After reading http://code.google.com/apis/gdata/docs/auth/overview.html it seems to me that OAuth is the most secure way to achieve your goals. Google recommends OAuth or AuthSub over ClientLogin for Web Applications. In addition using OAuth and AuthSub prevents your application from ever having control of the users email and password meaning you dont need to take the extra steps to protect and update the information. Between OAuth and AuthSub, OAuth is more universally adopted, and more secure due to the fact that requests are signed. Hope that helps.
EDIT: So I misunderstood exactly what your application was doing, if you are only using your google account any method of authentication is probably fine, that said google recommends OAuth or AuthSub for web apps. However the important thing to find out about OAuth and AuthSub is what the life of the token is. If there is no way to make the token last for a long time (months, years) then I would try to use ClientLogin, because then your application will always be able to login to the account. As a side note however for security I would recommend you NOT use your primary google account for the application instead create a second account and simply share the calendar with your primary account, that way if you application was compromised you would not lose your primary google account.