This library is based on the https://keycloak.gitbooks.io/securing-client-applications-guide/content/topics/oidc/javascript-adapter.html[{{book.project.name}} JavaScript adapter], which can be integrated to allow your client to obtain permissions from a {{book.project.name}} Server.
* Handle responses from a resource server protected by a <<fake/../overview.adoc#_enforcer_overview, {{book.project.name}} Policy Enforcer>> and obtain a requesting party token (RPT) with the necessary permissions to gain access to the protected resources on the resource server.
** In this case, the library can handle whatever authorization protocol the resource server is using: <<fake/../../service/authorization/authorization-api.adoc#_service_authorization_api, UMA>> or <<fake/../../service/entitlement/entitlement-api.adoc#_service_entitlement_api, Entitlements>>.
* Obtain permissions from a {{book.project.name}} Server using the <<fake/../../service/entitlement/entitlement-api.adoc#_service_entitlement_api, Entitlement API>>.
In both cases, the library allows you to easily interact with both resource server and {{book.project.name}} {{book.project.module}} to obtain tokens with
permissions your client can use as bearer tokens to access the protected resources on a resource server.
If a resource server is protected by a policy enforcer, it responds to client requests based on the permissions carried along with a <<fake/../keycloak-enforcement-bearer.adoc#_enforcer_bearer, bearer token>>.
Typically, when you try to access a resource server with a bearer token that is lacking permissions to access a protected resource, the resource server
The value of the `WWW-Authenticate` header depends on the authorization protocol in use by the resource server. Whatever protocol is in use, you can use a `KeycloakAuthorization` instance to handle responses as follows:
* `onGrant`: The first argument of the function. If authorization was successful and the server returned an RPT with the requested permissions, the callback receives the RPT.
* `onDeny`: The second argument of the function. Only called if the server has denied the authorization request.
* `onError`: The third argument of the function. Only called if the server responds unexpectedly.
Most applications should use the `onGrant` callback to retry a request after a 401 response. Subsequent requests should include the RPT as a bearer token for retries.
* `onGrant`: The first argument of the function. If authorization was successful and the server returned an RPT with the requested permissions, the callback receives the RPT.
* `onDeny`: The second argument of the function. Only called if the server has denied the authorization request.
* `onError`: The third argument of the function. Only called if the server responds unexpectedly.
If you have already obtained an RPT using any of the authorization functions provided by the library, you can always obtain the RPT as follows from the authorization object (assuming that it has been initialized by one of the techniques shown earlier):