The oauth_dynamic_client_registration feature implements the dynamic registration of OAuth 2.0 client applications with authorization servers. Essentially, clients can just hit an endpoint (by default, /register) with the appropriate metadata and get a client application back, with all the data needed to start integrating.
Cloud or internal authorization servers, with a bunch of services (potentially resource servers) which need to authorize communication with each other, and need a more streamlined/automated way of doing it.
plugin :rodauth do
enable :oauth_dynamic_client_registration
# setting up authentication is mandatory
before_register do
oauth_application_params[:account_id] = account_from_registration_token(request.env["HTTP_AUTHORIZATION"])
end
end
# if you want to enable client registration routes
rodauth.load_registration_client_uri_routes
The successful call of this endpoint will create a new oauth client application.
The metadata to be sent in the payload is defined in the SPEC, after which a response will be returned, with a few extra parameters: the newly-generated "client_id", a newly-generated "client_secret" (if client didn’t specify it in the request), or a "client_registration_token" among other things.
By default, access to the “register” endpoint errors out; authorization is mandatory, and it’s up to the user to set its own mechanism.
You can override this behaviour by overwriting the before_register rodauth hook:
# an example of one-time tokens to by used by accounts
plugin :rodauth do
enable :oauth_dynamic_client_registration
before_register do
token = request.env["HTTP_AUTHORIZATION"][/Bearer (.+)/, 1]
grant = db[:one_time_grants].returning.delete(token: token).first
register_throw_json_response_error("invalid_token", "no token mate") unless grant
# by default, client applications aren't bound to an account, so make sure
# you do it if you can.
@oauth_application_params[oauth_applications_account_id_column] = grant[:account_id]
end
end
If rodauth.load_registration_client_uri_routes is loaded the client registration uri is also reachable for existing oauth applications, via the GET, PUT and DELETE HTTP methods. All methods require usage of the client registration token (provided in the POST /register response) as a bearer token via the Authorization header. PUT will accept the same parameters as POST.