We have an app service with private/public key credentials for authentication. We initialize an
OAuthApi with the following configuration :
var privateKey = File.ReadAllText(“privatekey.json”);
var config = new Configuration
{
OktaDomain = “https:devoktainstance.okta.com”,
AuthorizationMode = AuthorizationMode.PrivateKey,
ClientId = “clientIdreplaced”,
Scopes = [“okta.apps.manage”],
PrivateKey = new JsonWebKeyConfiguration(privateKey),
};
var oAuthApi = new OAuthApi(config);
var accessToken = await oAuthApi.GetBearerTokenAsync(); // we receive what it seems to be a valid token with correct scope granted.
We get accessToken back with correct claim for scopes:
“scp”: [
“okta.apps.manage”
]
However when trying to send a request to
{{url}}/api/v1/apps/{{applicationId}}/credentials/jwks
To add a new JWKs key in order to have and facilitate key rotation we received a 403 error:
{
“errorCode”: “E0000006”,
“errorSummary”: “You do not have permission to perform the requested action”,
“errorLink”: “E0000006”,
“errorId”: “oaeiShl7lazQcCxeUc2tLIIsg”,
“errorCauses”:
}
Even though as per documentation okta.apps.manage scope is granted in the application and set on token.
Documentation link : Add Json Web Key
We are considering the 2nd possibility to do key-rotation by providing an api/url to Okta for fetching dynamically the keys but we`re not comfortable with having an public api exposing this without an extra security/auth method for it.
Also Super Administrator is set in Admin roles.
What can we do and what are we missing here ?
While you can receive a token with this scope upon requesting it (and it being granted to the application), the application itself may not have permissions to the appropriate resource set based on the assigned admin roles.
What admin roles have you assigned to the API Service application you made within Okta? Does this admin role have sufficient permissions to manage applications?
Here’s a quick explanation of this Silent Downscoping from our docs:
The Okta org authorization server returns all scopes that you request. It returns all requested scopes as long as the client app is permitted to use that scope (granted to the client app). It doesn’t matter whether you have permissions for all the scopes that you request. If the scopes requested exist in the app’s grants collection, those scopes are sent back in the access token. However, when you make requests to perform actions that you don’t have permissions for, the token doesn’t work, and you receive an error.
For example, if you’re a Read Only Admin and request an access token that contains the okta.authorizationServers.manage scope and that scope exists in the client’s grants collection, the access token returned contains that scope. However, the access token doesn’t work when you try to modify an authorization server on /api/v1/authorizationServers because you lack the permissions.
Hi @andrea .
Yes, we are able to manage other aspects of applications such as activating/deactivating an application which also requires okta.apps.manage .
Could this be a bug ?