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)