An Authorization Server must exist within the DB. This can be done by making another entry to the
oauth_provider table of the RSA, as the RSA serves an an OAuth Client to the Authorization Server. This Authorization Server must be the same AS from which the service provider receives the bearer tokens representing user consent to allow the SP to have access to the use's resources. The RSA will use this Authorization Server to negotiate a PAT (An OAuth access token with the scope "uma_protection". It is used by a Resource Server to access an Authorization Server's protection and introspection APIs.).
INSERT INTO oauth_provider (id, version, date_created, last_updated, client_authentication_method, client_id, client_secret, default_scopes, issuer_uri, name)
VALUES (2, 1, now(), now(), "private_key_jwt", "rsa-oauth-client-id", "rsa-oauth-client-secret", "uma_protection", "https://auth-server-url, "Authorization Server Name");
An entry must be made into the Authorization Server's database representing this OAuth-relationship as well where the RSA serves as an OAuth Client to the Authorization Server. If 'private_key_jwt' is the chosen authentication method, the corresponding entry at the Authorization Server DB must also use the same authentication method and a JWKS URI of the RSA must be provided to the Authorization Server. In the configuration file, the
jwks_endpoint field captures the the path that shall be appended to the base URL as the RSA to serve as this JWKS URI value at the Authorization Server DB.