Skip to main content

Open Standards

SecureAuth supports industry-standard specifications for authentication, authorization, and secure data sharing. This page documents the open standards SecureAuth uses and implements, including specifications for OAuth, OpenID Connect, financial services security, and policy management. These standards help organizations build secure systems while maintaining compatibility across different platforms and services.

OAuth 2.0 basic profiles​

RFC6749 - The OAuth 2.0 Authorization Framework
Establishes how third-party applications can securely request access to user data without requiring users to share their passwords or credentials with those applications.

RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
Defines how applications use bearer tokens in HTTP requests to access protected resources, and requires that these tokens be protected from disclosure during storage and transmission.

RFC7662 - OAuth 2.0 Token Introspection
Enables applications to query an authorization server to verify whether an access token is still active and to retrieve information about what permissions and data access it grants.

RFC7636 - Proof Key for Code Exchange(PKCE) by OAuth Public Clients
Protects mobile and native applications from authorization code interception attacks by requiring applications to prove they initiated the authorization request using a cryptographic code verifier.

RFC7009 - OAuth 2.0 Token Revocation
Enables applications to inform the authorization server when access or refresh tokens are no longer needed, ensuring those tokens are immediately invalidated and cannot be used.

RFC8252 - OAuth 2.0 for Native Apps
Specifies security best practices for native and mobile applications using OAuth, requiring them to use the device's browser for authentication instead of embedded login screens.

OAuth 2.0 advanced profiles​

RFC8693 - OAuth 2.0 Token Exchange
Enables applications to exchange one type of security token for another, supporting scenarios where applications need to access multiple systems or where one service needs to act on behalf of another.

RFC8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
Enhances OAuth security by enabling clients to authenticate using digital certificates instead of shared secrets, and binding access tokens to specific certificates so only the certificate holder can use them.

RFC9126 - OAuth 2.0 Pushed Authorization Requests
Improves OAuth security by allowing applications to submit sensitive authorization details directly to the server before user interaction, reducing exposure of personal information and enabling earlier detection of invalid requests.

RFC9101 - The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request(JAR)"
Secures OAuth authorization requests by encoding them in signed and encrypted tokens instead of plain text, protecting request integrity, verifying the request source, and preventing tampering or monitoring during transmission.

RFC7591 - OAuth 2.0 Dynamic Client Registration Protocol
Enables applications to automatically register themselves with OAuth authorization servers, obtaining credentials and configuration without requiring manual administrator setup.

RFC8628 - OAuth 2.0 Device Authorization Grant
Enables devices with limited input or display capabilities, such as smart TVs and printers, to obtain user authorization by having users complete authentication on a separate device like a smartphone or computer.

RFC7521 - Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
Provides a framework allowing OAuth 2.0 to work with other identity systems by using cryptographically signed assertions for client authentication and obtaining access tokens, enabling integration across different identity platforms.

RFC7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
Specifies how to use JSON Web Tokens for authenticating applications to authorization servers and for requesting access tokens, providing an alternative to traditional shared secrets.

OpenID Connect (OIDC) profile​

OpenID Connect extends OAuth 2.0 by adding user authentication capabilities, allowing applications to verify who users are in addition to authorizing what they can access.

OpenID Connect Core
Adds authentication to OAuth 2.0 by enabling applications to verify user identity and obtain basic user profile information through standardized identity tokens and claims.

OpenID Connect Discovery
Enables applications to automatically discover OpenID Provider locations and configuration details without manual setup, streamlining integration across different providers.

OpenID Connect Dynamic Registration
Enables applications to automatically register themselves with OpenID Providers and receive credentials without manual administrator intervention.

OAuth 2.0 Multiple Response Type Encoding Practices
Specifies how authorization responses with multiple values should be encoded and transmitted securely, with different encoding methods for different types of sensitive information.

OAuth 2.0 Form Post Response Mode
Provides a more secure method for transmitting authorization response data by using HTTP POST submission instead of encoding parameters in URLs, reducing information exposure.

Advanced security profiles (FAPI, CIBA, JARM)​

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.

SecureAuth 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)
Enables parties to prove they possess a specific cryptographic key without revealing the key itself, supporting secure holder-of-key authentication scenarios where token recipients can verify key possession.

RFC7519 -JSON Web Token (JWT)
Defines a compact, URL-safe token format for securely transmitting information between parties, where data can be digitally signed to prove integrity or encrypted to protect confidentiality.

RFC7518 - JSON Web Algorithms (JWA)
Defines the cryptographic algorithms used for signing, encrypting, and managing keys in JSON Web technologies, establishing standard algorithm identifiers for interoperability across implementations.

RFC7517 - JSON Web Key (JWK)
Specifies how to represent cryptographic keys in JSON format for use in web security systems, enabling standardized exchange and management of keys across different applications and services.

RFC 7516 - JSON Web Encryption (JWE)
Defines a standard format for encrypting and protecting data using JSON-based structures, supporting confidentiality and integrity protection for secure data transmission between parties.

RFC7515 - JSON Web Signature (JWS)
Specifies how to digitally sign or apply integrity protection to data using JSON-based structures, ensuring that content has not been modified and verifying its source.

Industry initiatives​

SecureAuth uses and/or implements parts of the following specifications.

Consent Receipt
A standard format for documenting when users authorize organizations to collect and use their personal information. Consent receipts provide users with a clear, readable record of what data is being collected, why it's being collected, and how it will be used. This standard helps organizations comply with privacy regulations and data protection laws by creating transparent records of user permissions.

Secure Production Identity Framework (SPIFFE) - SPIFFE ID
A unique identifier that acts like a digital name tag for services and applications. SPIFFE IDs follow a standardized naming format (spiffe://trust-domain/workload-identifier) so services can be uniquely recognized and verified across your infrastructure. SecureAuth generates service identifiers for OAuth services using the SPIFFE standard.

Rego - OPA's native query language for Policy
A language for writing policy rules that automatically check whether data, systems, and configurations follow your organization's standards and guidelines. Rego makes it easy to define clear rules in human-readable format rather than complex code, so you can focus on what you want to enforce rather than technical implementation details.