I'm implementing OAuth for a number of providers using dotnetopenauth, which I've found to be very good so far.
I understand I need to implement IConsumerTokenManager to store the tokens and secrets in my database, which makes perfect sense. All good so far.
I'm slightly confused about two things though:
The microsoft OAuthWebSecurity class provides methods for registering clients for facebook and linkedin etc, but none of the constructor overloads accept IConsumerTokenManager - does this mean they are using the InMemoryTokenManager under the hood, and if so does this mean I'll have to do custom implementations anyway in order to use my token manager?
I've implemented a custom OAuth2Client (DotNetOpenAuth.AspNet.Clients.OAuth2Client) for google, and there is no overload in the constructor for the OAuth2Client base class which accepts an InMemoryTokenManager - is this class required for OAuth2 is or is the token management handled differently?
Thanks in advance for any help!
IConsumerTokenManager only applies to OAuth 1.0, but Facebook and Google use OAuth 2.0, so your clients don't need to implement this interface.
Related
We are trying to split apart Authorization and Authentication into two separate services. Both will use Identity Server 4. We may someday add in additional external Authentication providers. I believe Federated Gateway is the term (http://docs.identityserver.io/en/release/topics/federation_gateway.html?highlight=Federation)
My research so far indicates we are able to setup Authorization as External Providers and set [LocalLoginEnabled] to false. This works fine for web apps, since it redirects along the traditional flows. Our requirement is to have both Web-based and client-apps (Windows and Mobile) calling our solution. This would need Implicit or Resource Owner (password) flows.
Looking for guidance on the best way to set this up. I'm tempted to write a custom endpoint API to relay the authentication to authentication instance.
QUESTION:
How can I achieve "password flow" between two ID4 instances (Authorization + Authentication)?
Thanks in advance!
After much research and little guidance, I decided to take a leap and just created a new API Endpoint used only for Resource Owner / Password Grant Types. This API simply validates the necessary information was present grant-type, secret, user/pwd etc... and then relays it to the Authentication instance. There may be more "elegant" ways of doing this, but this one seems to be working.
Hope this might help someone.
Although my original answer worked, it was not the best way to accomplish my end result. Instead of creating a new endpoint, I am able to inject my own handling of password grants by extending the IResourceOwnerPasswordValidator. I can then have a single endpoint for all authorization. This solution is more "natural" and falls inline with the intended architecture.
The IResourceOwnerValidator interface just implements one function...
public Task ValidateAsync(ResourceOwnerPasswordValidationContext context)
A much more elegant solution.
I'm confused on how the Web API implements the authentication?
I have gone through the links 1.
Link1
Link2
and need to summarize what I understood.
Owin katana is a mechanism that can be implemented for authorization.
There will be Iprincipal which can be created either in the host or
in the httpmodule which will be attached to the currentthread to
validate.
Token based authentication implements owin.
I have very little idea about the authentication mechanism in web api. If someone can help me to understand this, It would be great.
I have the following doubts.
Owin is a new way of authentication in MVC? or its already exists as
a part of windows and form based authentication?
If I wrote a module to authenticate what are the different ways I can use to authenticate an api method/controller?
The answer to your question could be quite big, I will try to give you some guidelines:
Katana is Microsoft's implementation of the OWIN standard
https://learn.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/getting-started-with-owin-and-katana
Token based authorization is supported by OWIN and , therefore, by Katana.
There are two very usual ways to implement this token authorization, you can use Windows Authorization
https://learn.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/enabling-windows-authentication-in-katana
or you can use a more standard and recommendable way using OAuth:
https://learn.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server
With ASP.net (netfx, not core), you use attributes on controller level to provide the metadata necessary to implement the authorization and authentication.
I am in the process of re-writing some very outdated .NET 2.0 SOAP web services for my company. So I am rewriting them using MVC3 RESTful. This method would simplify the usage of our services for our client base (over 500 clients using our current SOAP services) who are on multiple platforms and languages.
I am looking for a BETTER method of authorization for the RESTful services, than what the previous developer used for our .NET 2.0 SOAP web services (he basically just had the client pass in a GUID as a parameter and matched it in code behind).
I have looked into oAuth and I want to use it, HOWEVER, I have been told, from my superiors, that this method is TOO complicated for the "level" of clients that connect to our services and want me to find another simpler way for them to connect but still have authorization. Most of our clients have BASIC to no knowledge of programming (either we helped them get their connection setup OR they hired some kid to do it for them). This is another reason that the superiors want a different method, because we can't have all 500+ (plus 5-10 new clients a day) asking for help on how to implement oAuth.
So, is there another way to secure the MVC3 services other than passing a preset GUID?
I have looked into using Windows Authentication on the services site, but is this really logical for 500+ clients to use?
Is there an easy and secure method of authorizing multiple users on multiple platforms to use the MVC3 RESTful services that a end-client can implement very easily?
Thanks.
If you don't want anything too complicated, have a look at Basic HTTP Authentication. If you use it over SSL then it should be safe enough and also easy enough to implement for your clients. The Twitter API actually used this up until a few months ago when they switched to OAuth.
You want to distinguish between authentication and authorization. What you are looking for is authentication and indeed as Caps suggests, the easiest way may be to use HTTP BASIC authentication along with SSL to make the password is not compromised.
You could look into other means of authentication e.g. DIGEST or more advanced using ADFS or SAML (ADFS could be compelling since you're in .NET). Have a look at OpenID Connect too - it is strongly supported by Google and has great support.
Once you are done with that, you may want to consider authorization - if you need it that is - to control what a given client can do on a given resource / item / record. For that you can use claims-based authorization as provided in the .NET framework or if you need finer-grained authorization, look into XACML.
OAuth wouldn't really solve your issue since OAuth is about delegation of authorization i.e. I let Twitter write to my Facebook account on my behalf.
HTH
Is there a .NET OAuth library specifically designed to work against Twitter? Maybe even something to support MVC? A base controller maybe.....
I am currently using DotNetOpenAuth; it works well enough but seems overkill, in some places too complex and based on documentation more focused on openid.
Yes, several in fact. LinqToTwitter and TweetSharp are both .NET free libraries for calling into Twitter. DotNetOpenAuth has a longer history in OpenID than OAuth, but OAuth is very much a first class scenario for DotNetOpenAuth. That said, DotNetOpenAuth is strictly a protocol-level library, so higher-level libraries make calling Twitter much easier and I would highly recommend one of those.
Can you use oAuth to only authenticate like you can with Twitter?
If you check Google's docs at http://code.google.com/apis/accounts/docs/OAuth2.html you'll find that the scope (meaning, the service you're supposed to ask permission to) is a required field.
It may be a turn off for many users if you ask them to access their contact list when the most you really do is authenticate, so I rather stick with OpenID which is designed just to retrieve the UID.
So, the answer is really NO, unless you're planning on using an additional API with Google.
OAuth is an authorization protocol and can't be used for authentication only unless the provider defines a dummy scope which, in effect, authorizes you to access "nothing", or "basic user info" (name, e-mail, etc.).
AFAIK, Google provides no such "dummy" scope. However, they do implement OpenID for such authentication purposes, as the protocol is better suited for that task, anyways.
Yes you can there are many options it depens on your platform advice you to check
oauth.net
You can find there options for Java, .NET, Cold Fusion,PHP,etc.
There are many Frameworks that have OAuth capabilities, on Spring you can use this
Sounds like there is some plans afoot on this...
http://googlecode.blogspot.com/2011/03/making-auth-easier-oauth-20-for-google.html?showComment=1300267218233#c6336940633709651714
some chap:
"Can someone help by pointing to the documentation for the API of "just get basic information for a user"
other chap:
"The problem is, that you get a lot of different login mechanisms because Twitter is using OAuth 1.0 (Or am I wrong?), Facebook is using OAuth 2.0 and Google is using OpenID for login. Please correct me if I´m wrong. So basically I have the same question.
Will Google support login for basic user informations with OAuth 2.0 for Google APIs?"
google dude:
"Today we're supporting OpenID for login, but we've heard your pain about mess of different identity protocols on the web. Stay tuned :)"
Seems to me, as OAuth2 covers authentication and authorization, it would make sense to allow basic info and make it easy on the integrator using one method for all
I'm plumping for this possibility anyway, hopefully by the time I'm ready to put my app live it will be available from Google - Facebook has this anyway and in my case that's a big enough draw