tombcghtech/api_guidelines huggingface dataset:
Defines a protocol for a lightweight HTTP and JSON-based Security Token Service (STS) — covering requests of tokens from an authorisation server.
RFC 8705
This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual TLS authentication with X.509 certificates.
OAuth clients are provided a mechanism for authentication to the authorisation server using mutual TLS.
OAuth authorisation servers are provided a mechanism for binding access tokens to a client’s mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token.
RFC 8707
This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorisation server about the identity of the protected resource(s) to which it is requesting access.
RFC 8725
This document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.
13. Appendix H — RFCs in development
These RFCs are pertinent to this guideline but are under development as at May 2022:
Table 8: RFCs in developmen
OAuth 2.0 JWT Secured Authorization Request
This document 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 property of the authorisation request is attained.
JWT Response for OAuth Token Introspection
The introspection response, as specified in OAuth 2.0 Token, is a plain JSON object. This specification extends the token introspection endpoint with the capability to return responses as JWTs.
This specification defines a profile for issuing OAuth 2.0 access tokens in JWT format. Authorisation servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner.
The OAuth 2.1 Authorization Framework
This is an in-progress update to version 2.0. Key points to note are:
* Proof Key for Code Exchange (PKCE) is required for all OAuth clients using the authorisation code flow
* redirect Uniform Resource Identifiers (URIs) must be compared using exact string matching
* the grants omitted are:
* the implicit grant
* the resource owner password credentials
* bearer token usage omits the use of bearer tokens in the query string of URIs
* refresh tokens for public clients must either be sender-constrained or one-time use.
This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0.
This document specifies a new parameter ‘authorization_details’ that is used to carry fine-grained authorisation data in the OAuth authorisation request.
Pushed Authorization Requests (PAR) enable OAuth clients to push the payload of an authorisation request directly to the authorisation server in exchange for a request URI value, which is used as reference to the authorisation request payload data in a subsequent call to the authorisation endpoint via the user agent.
OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response
This specifies a new parameter ‘iss’ that is used to explicitly include the issuer identifier of the authorisation server in the authorisation response of an OAuth authorisation flow. If implemented correctly, the ‘iss’ parameter serves as an effective countermeasure to ‘mix-up attacks’ which are aimed to steal an authorisation code or access token by tricking the client into sending the authorisation code or access token to the attacker instead of the honest authorisation or resource server.
OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer
This specification describes a mechanism for sender-constraining OAuth 2.0 tokens via a Proof-of-Possession mechanism (DPoP) on the application level and enables a client to demonstrate proof-of-possession of a public / private key pair by including a DPoP header (JWT) in an HTTP request, that enables the authorisation server to bind issued tokens to the public part of a client’s key pair.
This mechanism allows for the detection of replay attacks with access and refresh tokens.
OAuth 2.0 for Browser-Based Apps
This specification describes the current best practices for implementing OAuth 2.0 authorisation flows in applications executing in a browser.
An application that is dynamically downloaded and executed in a web browser, usually written in JavaScript. Also, sometimes referred to as a single-page application, or SPA.
One of the key recommendations is the use of PKCE.
14. Glossary of terms
DELETE One of the most common HTTP methods, DELETE is used to delete a resource specified by its URI.
POST One of the most common HTTP methods for retrieving from and sending data to a server, the POST method sends data to the server and creates a new resource. The resource it creates is subordinate to some other parent resource. When a new resource is POSTed to the parent, the API service will automatically associate the new resource by assigning it a new resource URI. In short, this method is used to create a new data entry.
PUT One of the most common HTTP methods for retrieving from and sending data to a server, the PUT method is most often used to update an existing resource. If you want to update a specific resource (which comes with a specific URI), you can call the PUT method to that resource URI with the request body containing the complete new version of the resource you are trying to update.
Zero Trust Network Access (ZTNA) A product or service that creates an identity- and context-based, logical access boundary around an application or set of applications. The applications are hidden from discovery, and access is restricted via a trust broker to a set of named entities. The broker verifies the identity, context and policy adherence of the specified participants before allowing access and prohibits lateral movement elsewhere in the network. This removes application assets from public visibility and significantly reduces the surface area for attack.
15. Glossary of acronyms
ABAC Attribute-based Access Control
ACL Access Control List
AD Active Directory
AFLA Abbreviated Language for Authorization
CA Certificate Authority
CIBA Client Initiated Backchannel Authentication
CRL Certificate Revocation List
DAC Discretionary Access Control
DB Database
DHE Diffie-Hellman Ephemeral
DMZ Demilitarized Zone
DPoP Proof-of-Possession mechanism
ECDHE Elliptic Curve DHE
FAPI Financial Grade API
FHIR Fast Healthcare Interoperability Resources
FIDO U2F FIDO Alliance Universal Second Factor
GETS Government Electronic Tender Service
HEART Health Relationship Trust
HMAC Hash-based Message Authentication Code
HOTP HMAC-based One-Time Password
HPP HTTP Parameter Pollution
IETF Internet Engineering Taskforce
IP Internet Protocol
JSON Javascript Object Notation
JWA JSON Web Algorithms
JWE JSON Web Encryption
JWK JSON Web Key
JWS JSON Web Signature
MAC Message Authentication Code
MFA Multi-factor Authentication
MTLS Mutual Transport Layer Security
NZISM New Zealand Information Security Manual
OAuth Open Authorization
PAP Policy Administration Point
PDP Policy Decision Point
PEP Policy Enforcement Point
PIP Policy Information Point
PKCE Proof of Key for Code Exchange
PNZ Payments New Zealand
RAML REST API Modeling Language
RBAC Roles-based Access Controls
RFC Request for Comments
RO Resource owner
RS Resource server
SAML Security Assertion Markup Language
SCIM System for Cross-domain Identity Management
SEO Search Engine Optimisation
SOAP Simple Object Access Protocol
SPML Service Provisioning Markup Language
STS Security Token Service
TLS Transport Layer Security (superseded SSL)
TOTP Time-based One-time Password
UMA User-Managed Access
URI Uniform Resource Identifier
URN Uniform Resource Name
WADL Web API Description Language
XACML eXtensible Access Control Markup Language
XML eXtensible Markup Language
ZT Zero Trust
16. Further reading
HTTP 1.1 Standards RFCs — IETF:
RFC7230 HTTP/1.1: Message Syntax and Routing
RFC7231 HTTP/1.1: Semantics and Content
RFC7232 HTTP/1.1: Conditional Requests
RFC7233 HTTP/1.1: Range Requests
RFC7234 HTTP/1.1: Caching
RFC7235 HTTP/1.1: Authentication
RFC7236 HTTP/1.1: Authentication Scheme Registrations
RFC7237 HTTP/1.1: Method Registrations
NZ Protective Security — Protective Security Requirement (PSR)
OpenAPI Specification — GitHub
OWASP API Security Project — OWASP
OWASP REST Security — REST Security Cheat Sheet
OWASP Secure Coding Principles — OWASP
OWASP Top Ten Project — OWASP
Reserved JavaScript Keywords — W3Schools
REST API Resource Modelling — Thoughtworks
Strategy for a Digital Public Service
Using HTTP Methods for RESTful Services — REST API Tutorial
Identity relates to how a person (or thing) is represented and how this is used to access services or information. See What is digital identity.
Provisioning standards provide the framework for managing the provisioning of user and their access to APIs, for example, the process for internal or external developers gaining access to API development and publishing services.