Granted Authorization Operations

Queries#

The Granted Authorization GraphQL API allows the querying of granted authorization:

• By an owner, which can return zero or more results.

grantedAuthorizationsByOwner(
    username: String!
    first: Int
    after: String
): GrantedAuthorizationsConnection!

• By an owner and client identifier, which can produce zero or one results.

grantedAuthorizationsByOwnerAndClient(
    username: String!
    clientId: String!
    first: Int
    after: String
): GrantedAuthorizationsConnection!

Querying granted authorizations currently requires querying all delegations for a user or for a user and client identifier. To protect the system performance and stability, the number of queried delegations is limited. When that limit is exceeded, the returned granted authorizations may be incomplete and not reflect all the existing delegations for the query criteria. This is communicated in the query result via the warnings field present in the GrantedAuthorizationConnection type, containing an entry with the value INCOMPLETE_RESULT.

Note that this should only happen in uncommon situations, where the same user has hundreds of delegations, i.e., performed hundreds of authorization requests.

Mutations#

The Granted Authorization GraphQL API also allows the revocation of granted authorizations:

• By an owner, which results in the revocation of all delegations with that owner.

revokeGrantedAuthorizationsByOwner(
    username: String!
    first: Int
    after: String
): RevokeGrantedAuthorizationPayload!

• By an owner and client identifier, which results in the revocation of all delegations with that owner and client identifier.

revokeGrantedAuthorizationsByOwnerAndClient(
    username: String!
    clientId: String!
    first: Int
    after: String
): RevokeGrantedAuthorizationPayload!

The limitation described in the previous section also applies to mutations. However, in this case the mutation operation will fail if the number of delegations to revoke exceeds a limit, instead of doing a partial revoke. This way the Curity Identity Server ensures all delegations are revoked or none are revoked.

The success or failure to revoke all delegations of a granted authorization is communicated through the success field present in the RevokeGrantedAuthorizationPayload. This type also contains an asynchronous field, indicating whether the revocation was already synchronously performed (value will be false) or if the revocation will be performed asynchronously (value will be true). Currently, all successful revocations are performed synchronously, however in the future some may be performed asynchronously.

GraphQLObligation.CanDeleteAttributes obligation#

Revocation of granted authorizations is considered to be a delete operation. However, the GraphQLObligation.CanDeleteAttributes obligation is not currently enforced, i.e., it will be ignored even if an authorization manager returns one in a revocation operation authorization decision.

Note that it is still possible to control the access to granted authorization revocation via an authorization manager.

• The configured authorization manager is always called before performing the revocation and a deny response will result in the revocation not being performed.
• If the authorization manager returns a GraphQLObligation.BeginOperation, then this obligation will be called before the revocation is performed. If this obligation denies the operation then the revocation will not be performed.

It is only the enforcement of the GraphQLObligation.CanDeleteAttributes obligation that isn’t currently supported.