- OAuth 2.0 Tutorial
- OAuth 2.0 - Home
- OAuth 2.0 - Overview
- OAuth 2.0 - Architecture
- OAuth 2.0 - Client Credentials
- Obtaining an Access Token
- Accessing a Protected Resource
- OAuth 2.0 - Extensibility
- OAuth 2.0 - IANA Considerations
- OAuth 2.0 Useful Resources
- OAuth 2.0 - Quick Guide
- OAuth 2.0 - Useful Resources
- OAuth 2.0 - Discussion
- Selected Reading
- UPSC IAS Exams Notes
- Developer's Best Practices
- Questions and Answers
- Effective Resume Writing
- HR Interview Questions
- Computer Glossary
- Who is Who
OAuth 2.0 - Assertion
Assertion is a package of information that makes sharing of identity and security information easier across various security domains.
It holds the data about the subject, circumstances under which assertion is considered valid, such as where and when it can be used.
Entity that creates or protects the assertion is called as the Issuer.
Entity that consumes the assertion depending on its information is called as the Relying Party.
Assertions are of two general types. They are −
Bearer Assertions − Any entity can use assertion to obtain access to the associated resources, wherein an entity can be in-charge of bearer assertion.
Holder-of-key Assertions − In this case, the entity must demonstrate the possession of additional cryptographic material, if it wants to access associated resources.
TThe following figure depicts the third party created assertion.
Step 1 − This is the first case where the client first requests assertion from third party entity, which is usually known as the "token service" or "security token service". Token service is capable of issuing, renewing, validating, and transforming security tokens to the client.
Step 2 − The token service fulfils the client's request by granting assertion.
Step 3 − A trust relationship exists between the token service and the relying party. The client then issues assertion to the relying party.
Step 4 − The relying party validates assertion and notifies the client about the status.
The following figure depicts the self-issued assertion.
Step 1 − This is the second case in which the client itself creates assertion locally. It doesn't have to request for assertion from the third party entity.
Step 2 − The client then issues the created assertion to the relying party.
Step 3 − The relying party validates assertion and notifies the client about the status.
Using Assertions as Authorization Grants
Using the following HTTP request parameters, the client includes the assertion and related information when using the assertions as authorization grants.
grant_type − The format of the assertion that is defined by the authorization server.
assertion − A particular serialization of the assertion defined by the profile documents.
scope − The authorization of the token is previously granted through some out-ofband mechanism while exchanging the assertions for access tokens. In that case, the scope that is requested must be equal to or less than the original scope granted to the authorized accessor.