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.
Related
I understand that there is a bit of an overlap between OAuth, OIDC and SAML. Especially if I understand right, Authentication is provided by both OIDC and SAML to achieve SSO.
However, my question is from a developer's perspective.
Is OAuth relatively easier to develop and maintain than SAML? Both as Identity provider and as a consumer.
Is any one of them more prone to bugs or hazzles than the other one?
With respect to user experience which one is more easier to setup with your enterprise Identity provider, "in general" ?
Finally, is there a recommended option when you as a consumer want to provide SSO? OIDC or SAML?
Just so you do not confuse this question to be yet another "SAML vs OIDC" : Say you want to provide SSO to your product via Azure AD, G-Suite or Okta etc. All of which support both OIDC and SAML, then would you go with OIDC or SAML?
OAuth is for authorization. OIDC and SAML are for authentication.
Whichever you choose, I would strongly recommend not implementing this yourself. Instead, choose an open-source or commercial product with a good track record. You don't want to be responsible for security weaknesses etc.
The choice of OIDC vs SAML often comes down to what's supported by third party sites you wish to SSO to. If this is purely internal, you may decide to use OIDC. If this is for SSO to third parties, you may decide to use SAML as this is much more commonly used in the corporate world.
I am a bit confused about the difference between OData and OAuth? Are they both protocols for authorization? Or they are used together?
Thay are totally different things:
OData
is a protocol for querying an endpoint and service information.
You are able to perform select and filters against it.
OData (Open Data Protocol) is an ISO/IEC approved, OASIS standard that defines a set of best practices for building and consuming REST APIs. It enables creation of REST-based services which allow resources identified using Uniform Resource Locators (URLs) and defined in a data model, to be published and edited by Web clients using simple HTTP messages.
The formal documentation is a bit broad, but I believe the examples are pretty interesting, note the filter parameter:
https://example.org/Airports?$filter=contains(Location/Address, 'San Francisco')
See source tutorial.
OAuth
is a protocol for authorization.
OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group.
OpenIDC
OpenIDC is an OpenID based authentication standard on top of OAuth.
I think it's worth to mention because this often is mentioned together with OAuth.
OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, which allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner.
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.
Our partner is trying to setup a PicketLink STS which according to spec is based on WS-Trust. I can't find any information whether or not WIF is supporting this. I know it supports WS-Federation which is an extension on WS-Trust. Most of the time both terms are used in conjunction so I don't know if WS-Trust alone is supported as well.
Thanks in advance.
Yes, WIF supports WS-Trust. The docs: http://msdn.microsoft.com/en-us/library/ee748475.aspx
It'd help if you explained the scenario a little bit more. Are you building a website? Are you trying to authenticate users on "PicketLink".
WS-Trust is generally used for "rich clients" (used for "active federation"). WS-Federation (and SAML 2.0) are typically used for web sites (used for "passive federation").
WIF can do WS-Trust and WS-Federation. It can't do SAML (the protocol). Confusion is often augmented by the fact that people use the word SAML to refer both to the protocol and the token format. WS-Federation uses SAML tokens. WIF understands SAML Tokens.
Please I would like someone to tell me if dotNetOpenAuth single-sign-on.
All I want to achieve is to be able to seamlessly logging to all domains without redirect to third party system for authorisation or Authentication within a mixture programming platforms e.g (PHP or .Net)
DotNetOpenAuth library is a simple library to implement Single Sign On for .NET based application. The only issue I faced was related to performance. It was found to be a known issue with a particular API that cause the sluggishnes.
DotNetOpenAuth can be used for SSO solutions, but each new web site a user visits does need to perform a redirect to the identity provider. In a controlled SSO environment, that provider may never appear to the user, so the login is totally transparent. There are a couple of samples of an SSO configuration that comes with the DotNetOpenAuth download.
DotNetOpenAuth will help you do what you want to do provided you can support OpenID from PHP. You need to implement a provider (the site that authenticates you against a DB or other store), and a consumer (the site you want to log into).
My recommendation would be to consider the authentication protocol you wish to use rather than a specific library at first. In the case if DotNet OpenAuth it has support for:
OpenID
OAuth
InfoCard
These are just a few of the protocols available. You should also look into the SAML family of protocols, in particular SAML 2.0.
There are implementations of SAML for PHP, .NET, and many other platforms. You might want to look at a comparison between OpenID and SAML in order to choose which is better for you.