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
Related
I'm working on a service that provides smart (hopefully) integration of different services supporting OAuth 2.0. The focus of our tool is on team work flow improvement, so we're combining Slack, GitHub, Asana (issue tracker), Cezanne (hr tool), etc.
We have ui and backend that work with all those tools (user is authorised to all of them, so I have required access and refresh tokens). We need to be able to hide different parts of the ui depending on person's role in a specific tool. Let's take GitHub as an example. The user can be a repository owner, contributor, company owner (for business account), etc, so those user might need different ui based on their rights.
Originally I was hesitant implementing authorisation on my own (another custom authorisation system is the last thing this world needs), I wanted to take advantage of other services' authorisation mechanisms and just create a lightweight wrapper around them. It seemed like a reasonable idea at first, but I can't figure out how to implement it and Google doesn't give valuable advice which means: 99.99% I'm trying to do something stupid, 00.01% I'm trying to do something rare/innovative.
I hoped to take advantage of OAuth 2.0 but it doesn't seem to support what we need. The closest thing is scopes but it doesn't look very relevant to our scenario.
The only idea I have for now is to create our own authorisation system and integrate other services using kind of reverse engineering. So I would request user's GitHub account details using API and apply him roles in our system appropriately: Owner for repository A, contributor for repository B, owner of company C, etc. I will have to reverse-engineer the permission for each role (i. e. repository owner can not change company name). And we would have to keep user roles for each service: so instead of typical Admin/User/Manager/etc. we will get: OwnerOfGitHubRepository (for repositoryA), ManagerOfAsanaTeam (for team B), etc.
It would be awesome if OAuth 2.0 services had an endpoint that would return the permissions available for a current user.
I'm not a security engineer, so I might be missing something obvious. So wanted to ask you guys for advice before investing into the implementation mentioned above.
The word, "authorization", is used in two different contexts.
In one context, authorization means "who has what permissions". Solutions for this authorization is "identity management".
In the other context, authorization means "who grants what permissions to whom". Solutions for this authorization is "OAuth".
In some cases, you may have to handle these two authorizations simultaneously. See this question and this answer for details.
You tagged your question with identityserver4.
This Issue for identityserver3 from last year may interest you.
But I'm afraid most providers don't support this oauth2 profile (yet).
UMA seems to be an oauth2 way to enable fine grained authorization, but may not be the best solution.
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.
My understanding of OpenID is that it provides a way to have one site contain all your identity & peripheral info, but to let other OpenID-compliant (and user-trusted) sites re-use that info for identifying and authenticating the user. Essentially it minimizes the number of logins credentials (usernames & passwords) a user has for the internet.
My understanding of OpenSSO is that it allows you to sign-in to one site and automatically log-in to all other sites that the first site trusts. Essentially it minimizes the number of times a user has to log in to these different sites.
My understanding of OAuth is that it allows users to grant 3rd party sites certain access to their information located at one particular site. Essentially, like OpenSSO, it minimizes the number of times a user has to log in to these different sites. The different with OpenSSO is that OpenSSO logs the user into all the participating sites at once (with full privileges turned on), whereas OAuth grants finer-grained access to these participating sites.
So, first off, if anything I have said is incorrect, please begin by correcting me!
Assuming I am more or less correct, then I have the following questions/need clarification on the following items:
When would I choose OpenSSO over OAuth - just when I want to restrict access that the other participating sites have when a user logs in to one of them?
Are their different security risks for each of these technologies that I will have to consider and integrate into my app - or are they considered secure in and of themselves (basically can I rest assured that if my app uses them that my app is not open to any new attacks)?
Since these technologies are so closely related its hard for me to see the whole "forest through the trees" here - thanks in advance!
Not really the right comparison to be making. OpenID & OAuth are protocols, OpenSSO (now OpenAM) is an implementation of those and other protocols (SAML, OAuth, etc)
Generally speaking, the protocols for OpenID and OAuth are similar even though they originated with different use cases in mind. Today there is a lot of convergence around OAuth 2.0 for both federation (authentication) and authorization cases. The next generation of OpenID called OpenID Connect is built on top of OAuth 2.0 and precursors to this are already in place at Google, Facebook, Twitter, etc...
As for security, there are always some risks, particularly with implementation errors. Pick a good implementation and read the specs so you understand what the risks and countermeasures are.
OpenSSO is for you to log into one site and be logged into multiple sites.
OAuth lets one site extract your data from a second site (pull your tweets or facebook statuses) without the first site having to know how to log into the second site.
Like SO, I am gonna depend on many Open ID providers to provide user authentication and I will use my own authorization methods. but I'm still in development phase, and don't want to work with real OpenID providers currently, what approach can I use to test my users and their activities in the website (w/o TDD), to emulate real users but not really use Open ID providers.
No need to make auto-transfer of users into real OpenID servers (when moving to production mode) since the current users are just for testing purposes and Unit-test code.
I guess, I need a User Service layer which provides a higly abstracted way to deal with users, so that the move to the real Open ID providers can be smooth in the future and doesn't affect the logic of my already written code.
Using C#.Net 4, ASP.Net MVC 3, Ninject
DotNetOpenAuth provides both server and client portions of OpenID and can be used to run your own OpenID provider for local testing.
Give your site members their own OpenIDs with the provider support included in this library.
Sample relying party and provider web sites show you just how to do it.
I simply register my test id as user with various organisations. I don't see anything wrong with that. I get to see the various responses and their differences.
I found it terribly easy to code for openid consumer. Just need to understand the sequence of responses. Draw the UML sequence diagram to aid your understanding before you start coding. No need to fake openId. Otherwise, whip up an openid server yourself.
Your services shouldn't depend on OpenID. Just have OpenID plug into an authentication module to provide a local user principal. In development, you can have the auth module return a fake user principal with the permissions you desire.
In a beta environment you could turn on OpenID and use test accounts from any OpenID provider. Having to log in during the development phase will just slow down all the developers. Any authentication bug or internet outage will kill everyone's productivity.
I'm designing a new web application. Some quick points on it:
ASP.NET MVC Web Application
SQL Server 2008
Entity Framework ORM
3 User Roles: Anonymous, Registered, Administrators.
Anonymous users can view stuff, Registered Users can post stuff, Admins can do anything
Heavy social integration with Facebook, Twitter and the like.
I plan to use OpenId for authentication (DotNetOpenAuth)
So, pretty simple right? (famous last words)
Now my question is:
Should i provide OpenId as the only means of authentication, or should i
also give the user the option to log
in using my own authentication system?
So this is basically a "User Experience" question. Take the example of StackOverflow - you MUST signup with OpenId. It seemed fine to me, but what about the general public? Can i be happy with the fact that a user of my site must have an OpenId account? (or signup for one before using my site)
Is giving the user two options to login bad UX?
I realize this is a partially subjective question, but im just looking for advice on which road to take, some case studies would be helpful.
Thanks.
Any good answer to a subjective question begins with it depends. :-)
I think if your prospective user base is already fairly social-network engaged (as it sounds by your description), it will probably be just fine to have authentication handled by OpenId providers. The important part is providing an easy-to-use login process, and make it obvious that various providers are available for authentication (Yahoo, Google, etc.).
If your prospective user base is going to consist of new or inexperienced Internet users, even a simple OpenId implementation may be too confusing.
I, for one, find it annoying to have to create yet another account every time a visit a new website, and I suspect that more and more users are feeling the same way.
There's a decent set of responses to a similar question at https://ux.stackexchange.com/questions/78
The thing is that only OpenID won't cut it in you case mainly because of Facebook and Twitter who aren't OpenID providers. Both use OAuth 2 for authetication. Wikipedia says this about it:
OAuth (Open Authorization) is an open standard for authorization. It allows users to share their private resources (e.g. photos, videos, contact lists) stored on one site with another site without having to hand out their credentials, typically username and password.
and this:
OAuth is a service that is complementary to, but distinct from, OpenID.
The DotNetOpenAuth also supports OAuth and the latest CTP release implements the OAuth 2 draft 10. Mind you that the OAuth 2 specification is still being developed and is expected to be finalized by the end of 2010. OAuth 2 also isn't backward compatible with OAuth 1.