+--------(A)- Initial Access Token (OPTIONAL) | | +----(B)- Software Statement (OPTIONAL) | | v v +-----------+ +---------------+ | |--(C)- Client Registration Request -->| Client | | Client or | | Registration | | Developer |<-(D)- Client Information Response ---| Endpoint | | | or Client Error Response +---------------+ +-----------+
图中所示的抽象OAuth 2.0客户机动态注册流描述了客户机或开发人员与此规范中定义的端点之间的交互。此图没有显示错误条件。这个流程包括以下步骤
可选地，向客户端或开发人员发出初始访问令牌，允许访问客户端注册端点。向客户端或开发人员发出初始访问令牌的方法超出了本规范的范围。
客户端或开发人员可以选择发布一个软件声明，以便与客户端注册端点一起使用。向客户端或开发人员发出软件声明的方法超出了本规范的范围。
客户端或开发人员使用客户端所需的注册元数据调用客户端注册端点，如果授权服务器需要初始访问令牌，则可以选择包含来自(A)的初始访问令牌。
授权服务器注册客户机并返回客户端注册的元数据， 在服务器上唯一的客户端标识符，以及一组客户端凭据，如客户端机密(如果适用于此客户端)。
授权类型与响应类型之间的关系
描述的grant类型和响应类型值是部分正交的，因为它们引用传递到OAuth协议中不同端点的参数。但是，它们是相关的，因为客户机可用的grant类型影响客户机可以使用的响应类型，反之亦然。例如，包含授权代码的授权类型值意味着包含代码的响应类型值，因为这两个值都定义为OAuth 2.0授权代码授权的一部分。因此，支持这些字段的服务器应该采取步骤，以确保客户机不能将自己注册到不一致的状态，例如，通过向不一致的注册请求返回无效的客户机元数据错误响应。
下表列出了这两个字段之间的相关性。
+-----------------------------------------------+-------------------+ | grant_types value includes: | response_types | | | value includes: | +-----------------------------------------------+-------------------+ | authorization_code | code | | implicit | token | | password | (none) | | client_credentials | (none) | | refresh_token | (none) | | urn:ietf:params:oauth:grant-type:jwt-bearer | (none) | | urn:ietf:params:oauth:grant-type:saml2-bearer | (none) | +-----------------------------------------------+-------------------+
向授予类型或响应类型参数引入新值的此文档的扩展和概要文件必须记录这两种参数类型之间的所有通信。
如果发送任何人类可读的字段时没有使用语言标记，那么使用该字段的各方不能对字符串值的语言、字符集或脚本做出任何假设，而且字符串值必须按照在用户界面中显示的位置使用。为了促进互操作性，建议客户端和服务器除了使用任何特定于语言的字段外，还使用不使用任何语言标记的人可读字段，并且建议发送的任何不使用语言标记的人可读字段包含适合在各种系统上显示的值。
例如，软件声明可以包含以下声明：
{ "software_id": "4NRB1-0XZABZI9E6-5SM3R", "client_name": "Example Statement-based Client", "client_uri": "https://client.example.net/" }
以下非标准示例JWT包括这些声明，并且使用RS256(仅用于显示目的)进行了非对称签名。并等到如下加密字符串。
eyJhbGciOiJSUzI1NiJ9. eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ. GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0 5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA
加密字符串由头，载荷以及密钥通过一系列的速算法生成，加密字符串与头，载荷以及密钥息息相关，一但加密字符串稍有改动，则无法解析正确解析无法通过验证。
通过加密字符串向授权服务器注册客户端。授权服务器为该客户端分配一个惟一的客户端标识符，可选地分配一个客户端机密，并将请求中提供的元数据与已发布的客户端标识符关联起来。该请求包括在注册期间为客户端指定的任何客户端元数据参数。授权服务器可以为客户端元数据中遗漏的任何项提供默认值。
注册端点，内容类型为application/json。该HTTP Entity Payload是一个由JSON组成的JSON文档对象和所有请求的客户端元数据值作为顶级成员那个JSON对象。
示例：