I am developing a WebAPI over my already existant MVC application, using the OAuth2 authorization system.
This API will allow my clients to request my users information. Currently, my users are stored in the Identity tables (ASPNetUsers). In my application, they are registering, logging in, etc... with the help of the Identity classes and methods.
The problem is here : I want to manage my API clients accounts, in an "Identity way", so I can authenticate them when they ask for Access Tokens. But I can't use the current users tables, as there is no common points between my clients and my users.
The perfect solution would be to have two Identity tables : one for my users, and one for my clients, but after my long-time searches, I figured it was not possible, or it would be a mess, at best.
I would not use ASP.NET Identity as a way to manage OAuth2 registered client applications. Even though some client applications (confidential) are indeed issued client credentials that's probably the only thing they share with a username/password user identity. It's a completely different thing and as such it should be managed and stored independently.
If you're thinking that this sounds like a lot of work, you're absolutely right. It isn't trivial to implement a custom username/password authentication that proves secure and implementing an OAuth2 authorization server is many times as complex.
If you really want/need to go that route then some mandatory reading:
The OAuth 2.0 Authorization Framework
OAuth 2.0 Threat Model and Security Considerations
JSON Web Token (JWT) (assuming you choose JWT as token format)
If you're still evaluating all your options I would also consider the possibility of delegating all the authentication/authorization work onto a third-party, Auth0 comes to mind, but I'm biased because I work there.
Related
As far as I understand, applications that we can login with our different accounts use OpenID Connect(A profile of OAuth2.0).
OAuth is for Authorization and OIDC is for authentication(It has ID Token-User Info Endpoint).
So, was it not possible to login to an application from another application account using OAuth before OIDC? (If possible, how?)
If plain OAuth can't be used for authentication, what is/was it used for?
I mean what does it do with 'authorization' exactly?
What does it get from the resource service with the access token?
I have always found the jargon around this unhelpful so I understand your confusion. Here is a plain English summary:
OAuth 2.0
Before OIDC apps used OAuth 2.0 to get tokens, and this involved optional user consent. The process of getting tokens was termed 'delegation'.
In practical terms though all real world OAuth 2.0 providers also included authentication in order for their system to be secure. How authentication was done is not defined in OAuth specifications.
OAuth is primarily about protecting data, where scopes and claims are the mechanisms. These links provide further info:
IAM Primer
Scope Best Practices
Claims Best Practices
OIDC
This just adds some clearer definition around how authentication messages before and after authentication should work:
A client simply includes an openid scope to use OpenID Connect
A client may force a login during a redirect via a prompt=login parameter
A client may request an authentication method via an acr_values parameter
The client receives an ID token (assertion) once authentication is complete, can digitally verify it if required, then use the information in it (eg a user name)
OIDC still does not define how the actual authentication works though.
Use them together
Pretty much all OAuth secured apps (and libraries) these days use both together, so that the authentication and delegation both use standards based solutions. It gives you the best application features and design patterns for doing the security well.
I have a DashboardApi and an EnterpriseApi on my system. May be one more later.
I am new at IdentityServer3 and I wonder solve my problem.
IdentityServer saves client applications that will use an api. So I have 2 or 3 api. Will I create IdentityServer for all api? Because DashboardApi will consume EnterpriseApi. EnterpriseApi will consume another api.
And users will login to Dashboard application. I could not imagine the organisation.
To answer the question: you may have one instance of IdentityServer being your identity provider/authority across different "resource" APIs as long as they all point back to that same authority when it comes to token validation.
Then an access token used for "DashboardApi" can be used by "EnterpriseApi". It is important to proxy the token properly and in my experience it would be advantageous to create different scopes for each API to have better access as to which calls may be used to proxy into the second API through the first (especially if user consent is a concern).
I am exploring the possibility of using OAuth 2.0 in future projects.
What I see is that OAuth is built on the concept of [Resource Owner]+[Web Site Client]+[Authorization Server]+[Resource Server]. A lot of the articles and tutorials in the internet talks about using Facebook, Twitter, etc. as the Authorization/Resource Server, which is all cool and good.
What I am struggling to mentally picture is if I am the one who is going to create my own Auth/Resource servers, why will I choose to go this way? What are the scenarios that otherwise may not be ordinarily be achieved through ASP.NET MVCs form based authentication and the [Authorization] attribute model?
Take a look at the RFC 6749 - it talks about usecases. Its good comprehensible RFC.
Usecase verbatim from RFC:
o Third-party applications are required to store the resource
owner's credentials for future use, typically a password in
clear-text.
o Servers are required to support password authentication, despite
the security weaknesses inherent in passwords.
o Third-party applications gain overly broad access to the resource
owner's protected resources, leaving resource owners without any
ability to restrict duration or access to a limited subset of
resources.
o Resource owners cannot revoke access to an individual third party
without revoking access to all third parties, and must do so by
changing the third party's password.
o Compromise of any third-party application results in compromise of
the end-user's password and all of the data protected by that
password.
Read Aaron's article - OAuth2-Simplified
Recently I learnt OAuth with help of Apigee,you can use anything like google API.
Here is my github project oauth20_apigee if it helps checkout.
It depends on what your short and long term goals are going to be. In my opinion, the short and dirty points are:
OAuth 2.0 is typically used to grant an application access to specific resources on behalf of the user which is a great mechanism for allowing 3rd party applications extend your product. So if you're building an API, then this would be great for you.
Likewise, it is beneficial in that it not only enables someone else to extend your product, but you can also extend theirs. For instance, you could create a trusted application for another product, they could link their customer directly to your module (for lack of a better term) without requiring a separate login, provided you support their token format (typically through the use of a federated identity provider)
If you build your application to support 3rd party OAuth authentication, you can improve the user's experience for registering with your site. By allowing them to use their choice of authentication (e.g. google, facebook, twitter, etc), they won't have to enter in a lot of personal information for umpteen millionth time. You just need to take their authentication and collect any additional information you need. Then create an internal account for them and associate their provider with their account
You can emulate single sign on through the use of a federated IDP, again, enhancing the user experience. For instance, if the user is already logged into google, your product can accept the token and simply request additional scope be added to the token without the user having to sign in again.
Implementing your own OAuth provider is a different beast and I'm not sure there's a ton of benefit to it unless you're planning on being the next Facebook or something.
I think there is a lot to gain from using OAuth. I believe that enabling these credentials in your web sites provides a significant advantage because millions of users already have accounts with these external providers. These users may be more inclined to sign up for your site if they do not have to create and remember a new set of credentials. Also, after a user has logged in through one of these providers, you can incorporate social operations from the provider.
However there is always the devils advocate and this article explains why OAuth could be a possible sercurity hole in an application if not implemented correctly:
http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
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
What is the difference between Claims based authentication vs What is provided by OAuth.
I am looking for conceptual difference and not technical difference. When do I choose Claims over OAuth and vice versa.
Claims based authentication is proposed by Microsoft and build on top of WS-Security. But OAuth is more a open source protocol that is being proposed to allow fetching resources from different portals based on a security token.
Claims also has this concept of token (SAML encoded or X509 certificates).
I am trying to understand when do I choose Claims over OAuth and vice versa.
Thanks
Claims-based identity is a way of decoupling your application code from the specifics of identity protocols (such as SAML, Kerberos, WS-Security, etc). It is not only for web applications and is implemented as a .NET library / framework called WIF.
OAuth is a specific protocol by which one web site can obtain user consent to access their private data on another web site.
It is not really the case that you would choose one or the other, in fact they are complementary. Potentially you could use both at once, if you were building a .NET web app that performed OAuth via the WIF.