The bmannconsulting.com website
1--- 2link: https://oauth.net/ 3tags: 4 - OAuth 5 - specification 6 - IETF 7 - login 8 - authorization 9wikipedia: https://en.wikipedia.org/wiki/OAuth) 10--- 11> OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the [IETF OAuth Working Group](https://datatracker.ietf.org/wg/oauth/about/). 12> 13> [OAuth 2.1](https://oauth.net/2.1/) is an in-progress effort to consolidate OAuth 2.0 and many common extensions under a new name. 14## RFC 7591 Dynamic Client Registration 15 16https://oauth.net/2/dynamic-client-registration/ 17 18> The OAuth 2.0 Dynamic Client Registration extension provides a mechanism for dynamically or programmatically registering clients. This spec was derived from the OpenID Connect Dynamic Client Registration spec and is still compatible with OpenID Connect servers. 19 20https://datatracker.ietf.org/doc/html/rfc7591 21 22> This specification defines mechanisms for dynamically registering 23 OAuth 2.0 clients with authorization servers. Registration requests 24 send a set of desired client metadata values to the authorization 25 server. The resulting registration responses return a client 26 identifier to use at the authorization server and the client metadata 27 values registered for the client. The client can then use this 28 registration information to communicate with the authorization server 29 using the OAuth 2.0 protocol. This specification also defines a set 30 of common client metadata fields and values for clients to use during 31 registration. 32 33## RFC 9449: OAuth 2.0 Demonstrating Proof-of-Possession (DPoP) 34 35https://oauth.net/2/dpop/ 36 37> [DPoP](https://datatracker.ietf.org/doc/html/rfc9449), or Demonstrating Proof of Possession, is an extension that describes a technique to cryptographically bind access tokens to a particular client when they are issued. This is one of many attempts at improving the security of [Bearer Tokens](https://oauth.net/2/bearer-tokens/) by requiring the application using the token to prove possession of the same private key that was used to obtain the token. 38 39https://datatracker.ietf.org/doc/html/rfc9449 40 41> This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens.[](https://datatracker.ietf.org/doc/html/rfc9449#section-abstract-1)