!!! Overview
[{$pagename}] is described in [RFC 7521]

!! Introduction from [RFC 7521].
An [assertion] is a package of information that facilitates the sharing of identity and security information across [Security Domains]. [RFC 7521] Section 3 provides a more detailed description of the concept of an [assertion].

[OAuth 2.0] [RFC 6749] is an [authorization] framework that enables a [third-party] [application] to obtain limited [delegation] access to a protected [HTTP] [resource].  In OAuth, those third-party applications are called [clients|OAuth Client]; they access protected resources by presenting an [Access Token] to the [HTTP] [Resource Server].  [Access Tokens] are issued to [clients|OAuth Client] by an [Authorization Server] with the (sometimes implicit) approval of the [Resource Owner].  These [Access Tokens] are typically obtained by exchanging an [Authorization Grant], which represents the [authorization] granted by the [Resource Owner] (or by a privileged administrator).

Several [Authorization Grant Types|Grant Types] are defined to support a wide range of client types and user experiences.  OAuth also provides an extensibility mechanism for defining additional grant types, which can serve as a [bridge between OAuth and other protocol frameworks|Identity Broker].

This specification provides a general framework for the use of [assertions] as [Authorization Grants] with [OAuth 2.0]. It also provides a framework for assertions to be used for [client|OAuth Client] [authentication].  It provides generic mechanisms for transporting assertions during interactions with an [Authorization Server]'s [token endpoint|Token_endpoint] as well as general rules for the content and processing of those assertions. The intent is to provide an alternative client [authentication] mechanism (one that doesn't send client secrets) and to facilitate the use of [OAuth 2.0] in client-server integration scenarios, where  the end user may not be present.

This specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations.  

For [instance|Example]:
* "[Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants] ([RFC 7522]) defines a concrete instantiation for [Security Assertion Markup Language] ([SAML]) 2.0 Assertions
* "[JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants]" [RFC 7523] defines a concrete instantiation for [JWTs].

Note: The use of assertions for [client|OAuth Client] [authentication] is orthogonal to and separable from using assertions as an [Authorization Grant]. They can be used either in combination or separately.  [Client|OAuth Client] assertion [authentication] is nothing more than an alternative way for a [Client|OAuth Client] to [authenticate] to the [token_endpoint] and [MUST] be used in  conjunction with some [Grant Type] to form a complete and meaningful [protocol] request.  Assertion [Authorization Grants] may be used with or without [Client|OAuth Client] authentication or identification.  Whether or not [Client|OAuth Client] authentication is needed in conjunction with an assertion [Authorization Grant], as well as the supported types of [Client|OAuth Client]  authentication, are policy decisions at the discretion of the [Authorization Server].

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]