pure-web | 使用stylish去除各大网站的广告

You can check this samples in github (by jelledruyts): Modern claims-based identity scenarios for .NET developers

It has samples of authentication and authorization using Azure Active Directory and/or Windows Server Active Directory Federation Services.

I suggest read this article Digital Identity for .NET Applications. It's a little old but is a good overview/review.

Tokens come in many different formats. For today’s .NET applications, however, three kinds of tokens are most important. They are the following:

1. User name/password token—This very simple token contains only two claims: the name of some subject and that subject’s password.
2. Kerberos ticket—More complex than a user name/password token, a ticket includes a subject’s name, the name of the subject’s Windows domain, and other information. Kerberos tickets that are issued by Active Directory also include an extension that contains security identifiers (SIDs) that identify the subject and the groups to which this subject belongs.
3. SAML token—The Security Assertion Markup Language (SAML) is an XML-based language that is owned by the OASIS multivendor standards group. Unlike the other token types that are described here, a SAML token doesn’t have a fixed set of claims defined for it. Instead, this kind of token can contain any claims that its creator chooses.

As soon as the claims are available, they can be used by Windows, the application, or both. The most common uses of claims include the following:

1. Authenticating the user(...)
2. Making an authorization decision(...)
3. Learning about this user(...)

Kind of Authentication:

1. Domain Based Authentication (eg Kerberos tickets):

A domain-based application accepts only a single token format with a fixed set of claims. One common example is a Windows application that accepts only Kerberos tickets. This kind of application is easy to create, and it works well inside a single Windows domain. The problem is that this simplistic approach to digital identity is no longer sufficient for many applications

1. Claim Based Authentication (eg. SAML tokens):

Unlike a domain-based application, a claims-based application can potentially accept multiple token formats with varying sets of claims. The token formats and claim sets that this application accepts are determined by the application itself.

Identity Technologies

• Active Directory (AD) Domain Services (full-featured directory service, token source for Kerbero tickets, etc)
• Active Directory Federation Services (ADFS) (support for claims-based applications, token source for SAML tokens
• Windows CardSpace
• Active Directory Lightweight Directory Services (subset of AD services)
• Identity Life-Cycle Manager (ILM) (synchronization between different identity stores)
• Windows Authorization Manager (tools for RBAC - role-based access control)
• Active Directory Rights-Management Services (RMS)

Because AD Domain Services implements Kerberos, the default token in a Windows environment is a Kerberos ticket. To use this default, an ASP.NET application specifies Windows Integrated Authentication, while a WCF application uses an appropriate binding, such as NetTcpBinding. In either case, the following figure illustrates how a Windows application with clients in the same domain might use a Kerberos ticket and AD Domain Services

First versions of AD FS only support SAML with web clients.

ADFS 1.0, supports only browser clients—a restriction that’s scheduled to change in the technology’s next release.

Hope it helps.