Dynamic client registration

RFC 7591 OAuth 2.0 Dynamic Client Registration Protocol and
RFC 7592 OAuth 2.0 Dynamic Client Registration Management Protocol

Provides resources for dynamically registering OAuth 2.0 clients with Key Bridge.

Client Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol.

Traditionally, registration of a client with an authorization server is performed manually. This resource can be used either for a client to dynamically register itself with authorization servers or for a client developer to programmatically register the client with authorization servers.

Delayed Client activation

Note that new Client registrations may be placed in a disabled state until reviewed and approved by an administrator.

Protocol Flow

        +--------(A)- Initial Access Token (OPTIONAL)
        |    ,---(B)- Software Statement   (OPTIONAL)
        v   v
    +-------------+                                      +---------------+
    |  Client     |--(C)- Client Registration Request -->|    Client     |
    |    or       |                                      | Registration  |
    |  Developer  |<-(D)- Client Information Response ---|   Endpoint    |
    +-------------+        or Client Error Response      +---------------+

Abstract Dynamic Client Registration Flow

Client registration is indempotent and can be repeated as many times as needed. A client may re-register at any time to refresh their OAuth credentials and to receive a new shared secret.

Initial Access Token

Client Registration requires an initial access token submitted as HTTP Bearer authentication per RFC 6750 (OAuth 2.0 Bearer Token Usage). Key Bridge IATs require, at minimum, the following claims. Additional claims may be required depending upon the application scope you wish to access.

Claim	Name	Value
iss	Issuer	The issuing agent. This should clearly identify the organization and, if possible, the issuing system. e.g. "Key Bridge IAT Generator"
sub	Subject	The Subject value assigned of your organization's account by Key Bridge. This is typically a UUID value.
aud	Audience	The string "`https://keybridgewireless.com`"
iat	Issued at	The current NumericDate value.
nbf	Not before	The current NumericDate value.
exp	Expiration	A NumericDate value of no more than 3600 second (5 minutes) in the future.
jti	JWT Id	A unique identifier for the JWT. Note that jti values cannot be reused; we recommend a random hash value.

NumericDate is a JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified instant. Values must be in Coordinated Universal Time (UTC) per RFC 3339 Section 4.1.

The initial access token is a JSON Web Token (JWT) signed, for enterprise users, by your Organization's private key. For convenience the IAT may be issued by Key Bridge but is typically generated by your client application.

Registration Access Token

Following registration your client can manage and update its record with Key Bridge using the OAuth 2.0 Dynamic Client Registration Management Protocol. All subsequent calls to client management resources must include the Registration Access Token issued by this system through the client registration endpoint.

Request and response

The following is a non-normative example request to Read a client configuration, where the Bearer token is the authorization server assigned registration_access_token value.

GET /register/s6BhdRkqt3  HTTP/1.1
Accept: application/json
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483

API resources

DELETE

delete Client{clientId}

https://keybridgewireless.com/sts/api/register/{clientId}

RFC 7592 OAuth 2.0 Dynamic Registration Management Client Delete Request
To deprovision itself on the authorization server, the client makes an HTTP DELETE request to the client configuration endpoint.
A successful delete action will (immediately) invalidate the "client_id", "client_secret", and "registration_access_token" for this client, thereby preventing the "client_id" from being used at either the authorization endpoint or token endpoint of the authorization server.

Headers and URI pattern

clientId

string

TEMPLATE

The client_id value. This was assigned by the authorization server during registration.

Reponse

Response

application/json

If the client has been successfully deprovisioned, the authorization server responds with an HTTP 204 No Content message.
If the client is not allowed to delete itself, the server responds with an HTTP 403 Forbidden message.

GET

read Client{clientId}

https://keybridgewireless.com/sts/api/register/{clientId}

RFC 7592 OAuth 2.0 Dynamic Registration Management Client Read Request
To read the current configuration of the client on the authorization server, the client makes an HTTP GET request to the client configuration endpoint, authenticating with its registration access token.

Headers and URI pattern

clientId

string

TEMPLATE

The client_id value. This was assigned by the authorization server during registration.

Reponse

Response

application/json

Upon successful update, the authorization server responds with an HTTP 200 OK message and a fully populated ClientInformationResponse payload as described in RFC 7592 Section 3.

POST

https://keybridgewireless.com/sts/api/register

RFC 7591 OAuth 2.0 Dynamic Registration
OAuth 2.0 endpoint allowing a client to be registered with the authorization server. This operation registers a client with the authorization server. The authorization server assigns this client a unique client identifier, optionally assigns a client secret, and associates the metadata provided in the request with the issued client identifier.
The posted object is a fully populated ClientRegistrationRequest per RFC 7591 Section 3.1.

Request

OpenIdClientRegistrationRequest

application/json

Reponse

Response

application/json

Upon a successful registration request, the authorization server returns a fully populated ClientRegistrationResponse per RFC 7591 Section 3.2.1 or an Error response per RFC 7591 Section 3.2.2.
The successful response contains the client identifier as well as the client secret plus all registered metadata about this client, including any fields provisioned by the authorization server itself.

PUT

update Client{clientId}

https://keybridgewireless.com/sts/api/register/{clientId}

RFC 7592 OAuth 2.0 Dynamic Registration Management Client Update Request
To update a previously registered client's registration with an authorization server, the client makes an HTTP PUT request to the client configuration endpoint. This request is authenticated by the registration access token issued to the client.
The posted object is a fully populated ClientUpdateRequest per RFC 7592 Section 2.2.

Headers and URI pattern

clientId

string

TEMPLATE

The client_id value. This was assigned by the authorization server during registration.

Request

ClientUpdateRequest

application/json

A JSON encoded Client Update Request message according to RFC 7592 OAuth 2.0 Dynamic Registration Management at 2.2.

Reponse

Response

application/json

Upon successful update, the authorization server responds with an HTTP 200 OK message and a fully populated ClientInformationResponse payload as described in RFC 7592 Section 3.