The RPT endpoint requires client authentication (i.e. client credentials). It's ok for some API's to use clients that use basic authentication. But all forms of basic authentication rely on shared secrets (i.e. the server knows the secret too). It is better security to use asymetric client credentials, where the server only knows a public key, and the client is the only one that knows the private key. UMA requires high security, so the use of private key authentication at the token endpoint is approriate. For this reason, instead of sending the client creds, an OAuth token (client credential grant) is used in lieu of sending the client creds with the request to the RPT endpoint (i.e. the token endpoint in OAuth jargon). But note: an OAuth token obtained via the client credential grant is not a PAT. A PAT was an UMA 1.x thing that does not exist in UMA 2.

Hi Michael, What you've said about using the `client_credentials` grant to protect the client secret makes sense. The problen I have is that the ValidationService in oxd seems to be treating the request to the token (RPT) endpoint as a PAT, and complains that the token does not have the `oxd` grant, which of course it wouldn't, because it's just the client credentials. ``` 2019-02-14 19:35:04,795 TRACE [org.xdi.oxd.server.service.ValidationService] access_token: a933b772-6035-4a6f-8b75-f531a9706b01, introspection: IntrospectionResponse{active=true, scopes=[], scope=[], clientId='@!3932.OBFUSCATED-FOR-TICKET', username='null', tokenType='bearer', expiresAt=1550173108, issuedAt=1550172808, subject='', audience='@!3932.OBFUSCATED-FOR-TICKET', issuer='https://auth.azya.io', jti='null', acrValues='null'}, setupClientId: @!3932.OTHER-OBFUSCATED-FOR-TICKET 2019-02-14 19:35:04,795 ERROR [org.xdi.oxd.server.Processor] ErrorResponseException{errorResponseCode=ErrorResponseCode{value='protection_access_token_insufficient_scope', description='protection_access_token does not have oxd scope. Make sure a) scope exists on AS b) setup_client is registered with 'oxd' scope c) get_client_token has 'oxd' scope in request'}} at org.xdi.oxd.server.service.ValidationService.validate(ValidationService.java:139) at org.xdi.oxd.server.service.ValidationService.validate(ValidationService.java:49) ``` Note that the introspected token `a933b772-6035-4a6f-8b75-f531a9706b01` was the client_credential token. I don't see any way pass that Validation error other than using the "PAT" originally provided via the oxd-https-extension API's /get-client-token resource...

Sorry, I was confused. The client token presented to the oxd API's, with the `oxd` grant, is used to protect the oxd API's themselves. If you are familiar with the architectrue of the Shibboleth SP, there is a service called `shibd`. This always runs on local host... because the authors of the Shibboleth SP didn't want to introduce the complexity of figuring out how to secure shibd over the network. We solved this problem by using OAuth to secure the oxd API's.

> When I completed the workflow using the https-extension however, I found myself needing to use the generated PAT to complete the RP-related activities, such as requesting the RPT. Surely I have something wrong here?! I'm not sure I really get the problem. > Should the same client be used for both RS & RP requests? No, usually RS and RP use separate clients. Each calls `setup_client` and `get_client_token` and thus get own `protection_access_token` (one token for RS and one token for RP) which is used to secure access to oxd API's. Important thing here is that this token MUST contain `oxd` scope. Error which you pasted above clearly says what to check. ``` protection_access_token does not have oxd scope. Make sure a) scope exists on AS b) setup_client is registered with 'oxd' scope c) get_client_token has 'oxd' scope in request ``` So does `oxd` scope exist in your AS? Does `setup_client` and `get_client_token` has `oxd` scope (for both RP and RS)? Check whether client LDIF in LDAP really have that scope (find client by `client_id`) > If not, what Bearer token should be used in the RP request for an RPT? The one which you get after `setup_client` and `get_client_token` commands. Same as for RS. Getting access to oxd API's is same for both RS and RP, it doesn't differ. > If there's anything else in my explanation that suggests I've misunderstood, please do point out! Can you explain exact problem ? In your second comment log snippet says that `get_client_token` returned you `protection_access_token` WITHOUT `oxd` scope. So indeed any call to oxd API's will fail with `protection_access_token_insufficient_scope`. Please follow error description and make sure `oxd` scope is really there (on AS, manually check `oxd` scope is in client entry, which is registered by setup_client and then finally `protection_access_token` has that scope). It's definitely configuration problem. One important note. `protection_access_token` which is used to secure oxd API's is one token, in UMA there is PAT (with `uma_protection` scope) which is used by AS Protection API, those are two different tokens. First is to secure oxd API's, second is to secure AS API's. https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0.html Actually you don't need to think about that second PAT because oxd handles it automatically. Let us know how it goes. Thanks, Yuriy Z

Forgot to get back to you on this, apologies. What hadn't really clicked for me was the idea that both the RP and the RS need to go through the Register Client phase independently in order to achieve this. I guess I struggled to map the impact of using the OXD service on top of the UMA 2.0 spec. With this important change, I believe everything is working as intended. All looks good, so moving onto implementation. Thanks again, both.

Thanks, Graham. If you have any feedback about how to make this clearer on the docs, we are always very appreciative of merge requests to our docs: https://github.com/GluuFederation/docs-oxd-prod/blob/3.1.4/3.1.4/sources/index.md