OK. I did some tests and I think we can't change the default behavior of the 'OAuth scope' agent. However, we can use some tricks thru irule. Since the 'OAuth scope' agent extracts the token from the 'Authorization Header' or 'Parameter' or 'Body', I think we can replicate the token value from the 'Custom header' to the 'Authorization' header. Let's say, you have the custom header named 'CustomAuthorization' and the custom header includes the valid token as a value. I think there are three different scenarios here.
1. If an API request includes the 'CustomAuthorization' header but doesn't include the 'Authorization' header.
- irule extracts the valid token value from the 'CustomAuthorization' header.
- irule inserts a new 'Authorization' header using the value of the token from the 'CustomAuthorization' header.
2. If an API request includes the 'Authorization' header but doesn't include the'CustomAuthorization' header.
- irule extracts the valid token value from the 'Authorization' header.
- irule inserts a new 'CustomAuthorization' header using the value of the token from the 'Authorization' header.
3. If an API request includes both the 'CustomAuthorization' header and the 'Authorization' header.
- irule extracts the valid token value from the 'CustomAuthorization' header.
- irule replaces the value of the 'Authorization' header with the value of the token from the 'CustomAuthorization' header.
Now, the 'OAuth scope' agent can extract the token value from the 'Authorization' header and proceed with the rest access policy.
If you configure the BIG-IP APM as an OAuth Resource Server, you also need to configure your access profile type to 'OAuth Resource-Server'. However, 'irule event' is not supported in the 'OAuth RS' access profile. To overcome this issue, you can configure the 'Layered Virtual Server' approach. You can create a dummy VS and attach the irule, then forward the traffic to the VS of the 'OAuth Resource Server'.