0

After reading about Microsoft's Claims-based identity, I don't understand what it brings more compared to OAuth (and therefore where is it better to use Claims-based identity rather than OAuth).

According to this Stack Overflow answer:

Claims-based identity is a way of decoupling your application code from the specifics of identity protocols [while] OAuth is a specific protocol.

This other answer claims that:

Claims-based security is required with OAuth

So it looks like:

  • Claims-based identity is more of an architecture while OAuth is a protocol.

  • Claims-based identity accepts multiple protocols, including OAuth.

  • OAuth uses Claims-based identity.

and obviously:

  • Claims-based identity can be used outside web applications,

  • Claims-based identity is Microsoft-oriented, which means excellent support in Microsoft products (such as SharePoint), but weaker support in other environments (such as a Python application hosted on a Linux server),

which means that there is a huge benefit of using Claims-based identity in corporate web, desktop and mobile applications within a company which relies heavily on Microsoft technologies and needs to provide authentication mechanism based on Active Directory and other providers, such as partner's OAuth providers.

Is my understanding of Claims-based identity right?

Community
  • 1
  • 1
Arseni Mourzenko
  • 50,338
  • 35
  • 112
  • 199

1 Answers1

1

I cannot see anything incorrect in your part of the text.

You could also talk about claims as an: "signed attribute-name-value pairs". The issuer "claims" that it is correct. Attribute-value pairs itself pre-dates any new "claims" terminology and is widely used (under different names).

Yes, Microsoft is now fully Attribute-value pairs (claims if you insist on the nice word). Into the toe nails, even the native Kerberos token now has them. In the past it was only SIDs and privileges. In .NET everything is now ClaimsIdentity.

paullem
  • 1,261
  • 7
  • 8