Get Started

Open Standards

Cloudentity is a cloud-scale provider for modern application authorization and identity-related open standard specifications to allow applications to move towards secure interaction models across applications and end users. Cloudentity also provides full conformance to major Open Data initiatives like OpenBanking, CDR, etc. that use the below standards as building blocks for sharing data across trusted organizations in an open API data economy. We are here to support the needs of organizations aiming for the highest level of security standards with the least amount of friction for standards adoption.

OAuth 2.0 basic profiles

RFC6749 - The OAuth 2.0 Authorization Framework

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage

Standards on how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a “bearer”) can use it to get access to the associated resources (without demonstrating the possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.

RFC7662 - OAuth 2.0 Token Introspection

Defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource.

RFC7636 - Proof Key for Code Exchange(PKCE) by OAuth Public Clients

OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced “pixy”).

RFC7009 - OAuth 2.0 Token Revocation

Defines endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant.

RFC8252 - OAuth 2.0 for Native Apps

OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user’s browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice.

OAuth 2.0 advanced profiles

RFC8693 - OAuth 2.0 Token Exchange

Defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.

RFC8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens

OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates.

RFC9126 - OAuth 2.0 Pushed Authorization Requests

Pushed authorization request (PAR) allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used asreference to the data in a subsequent call to the authorization endpoint.

RFC9101 - The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request(JAR)

Standard introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained. The request can be sent by value or by reference.

RFC7591 - OAuth 2.0 Dynamic Client Registration Protocol

Defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration.

RFC8628 - OAuth 2.0 Device Authorization Grant

The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.

RFC7521 - Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants

Defines a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms. Note that 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.

RFC7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

Defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication.

OIDC profile

OpenID Connect Core

Defines the core OpenID Connect functionality: authentication built on top of OAuth 2.0 and the use of claims to communicate information about the End-User.

OpenID Connect Discovery

Defines how clients dynamically discover information about OpenID Providers

OpenID Connect Dynamic Registration

Defines how clients dynamically register with OpenID Providers

OAuth 2.0 Multiple Response Type Encoding Practices

Defines several specific new OAuth 2.0 response types

OAuth 2.0 Form Post Response Mode

Defines how to return OAuth 2.0 Authorization Response parameters (including OpenID Connect Authentication Response parameters) using HTML form values that are auto-submitted by the User-Agent using HTTP POST.

OIDF FAPI profile

Financial-grade API Security Profile (FAPI) 1.0 – Part 1: Baseline

A secured OAuth profile that aims to provide specific implementation guidelines for security and interoperability.

Financial-grade API Security Profile (FAPI) 1.0 – Part 2: Advanced

A highly secured OAuth profile that aims to provide specific implementation guidelines for security and interoperability.

OpenID Connect Client-Initiated Backchannel Authentication Flow(CIBA) - Core 1.0

CIBA is an authentication flow like OpenID Connect that supports decoupled flows. However, unlike OpenID Connect, there is direct Relying Party to OpenID Provider communication without redirects through the user’s browser.

Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)

JWT-based mode to encode authorization responses parameters. All response parameters defined for a given response type are conveyed in a JWT along with additional fields used to further protect the transmission. Since there are different techniques to encode the JWT itself in the response to the client, namely query URI parameter, fragment component and form post, this draft defines a set of response mode values in accordance with OIDM corresponding to this techniques.

Cloudentity utilizes parts of below JSON Web Token, encryption, signature and key specifications to support the requirements of OAuth 2.0, OIDC, FAPI, and other advanced profiles or specifications.

RFC7800 -Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)

Defines how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter

RFC7519 -JSON Web Token (JWT)

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.

RFC7518 - JSON Web Algorithms (JWA)

This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.

RFC7517 - JSON Web Key (JWK)

A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification

RFC 7516 - JSON Web Encryption (JWE)

JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification.

RFC7515 - JSON Web Signature (JWS)

JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.

Industry initiatives

Cloudentity uses and/or implements parts of below specifications.

Kantara Initiative - Consent Receipt Specification

A Consent Receipt is record of authority granted by a Personally Identifiable Information (PII) Principal to a PII Controller for processing of the Principal’s PII. The record of consent is human-readable and can be represented as standard JSON. This specification defines the requirements for the creation of a consent record and the provision of a human-readable receipt. The standard includes requirements for links to existing privacy notices & policies as well as a description of what information has been or will be collected, the purposes for that collection as well as relevant information about how that information will be used or disclosed. This specification is based on current privacy and data protection principles as set out in various data protection laws, regulations and international standards.

Secure Production Identity Framework(SPIFFE) - SPIFFE ID

A SPIFFE ID is a string that uniquely and specifically identifies a workload. SPIFFE IDs may also be assigned to intermediate systems that a workload runs on (such as a group of virtual machines). SPIFFE IDs are a Uniform Resource Identifier (URI) which takes the following format: spiffe://trust domain/workload identifier. Cloudentity generates service identitifers for OAuth services in SPIFFE recommended format

Rego - OPA’s native query language for Policy

Rego for defining policy that is easy to read and write. Rego focuses on providing powerful support for referencing nested documents and ensuring that queries are correct and unambiguous.Rego is declarative so policy authors can focus on what queries should return rather than how queries should be executed. These queries are simpler and more concise than the equivalent in an imperative language.

Updated: Sep 27, 2022