Claim can represent anything about an identity. If you’re not familiar with OAuth Claims, they are like Roles in Active Directory (in fact Roles are just a specific type of Claim in the OAuth world). The difference is, Claims can represent anything.
Before we get too deep - I'd like to warn you: the rabbit hole here can go deep. Security and Identity is an area where you need to know enough to be literate and competent, but also - you could go deep enough to build an entire career in this space and never run out of new areas to grow in.
Let’s define some terms and set some ground rules:
- I am not a security or identity expert, you should really read some official docs.
- Two parties in any scenario: Identity Provider and Service Provider. Identity provider, digitally signs the claims about an identity. Service provider provides the service that the identity wants to use.
- Identify represents a person or service in a connected environment.
- Claims are anything that can be claimed about an Identity. Example of claims might be things like: name, employee id, email address, hair color, roles the person belongs to.
- OAth and Open ID Connect (OIDC) are used interchangeably. OIDC is a built on the OAuth standards, and is like an evolution of oAuth – both are open standards for SSO. SAML is an outdated SSO standard, oAuth and OIDC have replaced SAML.
- SSO and Federated Identities are terms used interchangeably.
Common Scenario (SharePoint):
There are generally two types of scenarios. IDP initiated or SP initiated. Let's look at a common SP Initiated scenario.
First, you make a request to the service provider, let’s say some cloud environment that your company has adopted like SharePoint.
When you make the request, the first thing the SP looks for is to see if you have a digitally signed, trusted claim. If the claims are missing, then you haven’t been properly authenticated yet. So, you get sent over to the IDP to get authenticated.
… this is where things get interesting. The IDP (Identity Provider) has a trust relationship with the Service Provider. So, when you log in to the IDP, it Authenticates you and sets your claims. But also, it might not be the one to authenticate you, it might have a trust relationship with another IDP. So, in the example above, fictional SharePoint trusts the IDP’s claims, and the IDP trusts your company’s Active Directory. Both AD and Azure AD can act as an IDP using oAuth or OIDC protocols.
Think of this as daisy chaining IDPs – the fact that the application (Service Provider) doesn’t need to know about your Active Directory directly – and only about its immediate IDP – is huge. It means the application can support a nearly infinite number of IDPs connecting to it without making any changes to the application.
Now you have a signed token that the Service Provider (SharePoint in this case) will trust, and it contains the claims about you.
Daisy chaining IDPs are great and all, Claims are even better.
Claims can be mapped from one Identity Provider to another. Without going into the details, I’ll just say this allows companies with wildly different identity schemes (roles and attributes) to be mapped to your application without needing to make changes to your application or their identity scheme. You offload the claims translation to your identity provider.
Let’s take another common scenario – building an expense system that is going to be used by multiple companies. In your application, you might have a claim called “Expense Approver”. But how that ability gets derived from one company to another might be completely different. In one place, you might need the Role “Manager”, another company might have a stored attribute like “Employee-Level” and maybe that needs to be above 52 to be able to approve an expense report.
Without Claims and Identity Provider mapping, either the code in the expense report tool would need to be updated, every time a new customer was onboarded – (making the onboarding process long and the code unstable) or every customer would have to adopt the Expense Report Schema, adding Expense Approver to their system – just for this one product, even though that company already has a way to derive that role.
Claims are the magical secret sauce of OAuth
That’s just for roles “Expense Approver” but Claims can contain much more. Maybe two people are both expense approvers, but the amount they can approve might be different. “Approval Amount” could also be a claim, and the IDP might have rules that assign different amounts based on various rules. Maybe managers can approve a certain amount, and VPs can approve a higher amount.
Claims make that possible – and the claims can have completely different rules on how they get assigned from all the different company IDPs … just so long as they end up getting mapped to the expected claims by the time they get back to the application in Step 4. Awesome.
If you’re working with OAuth and OIDC from .NET? Go check out my friend Joe’s posts. Seriously, he’ll get you up and coding.
One thought on “OAuth Claims are Magic”
Comments are closed.