Skip to content

Resources and permissions

In Goiabada, you can define both resources and permissions. Each resource can have multiple permissions associated with it.

You can assign these permissions to users, groups, or clients as needed.

When you pair a resource with a permission, it forms a scope, both in the authorization request and within the tokens.

Format: resource-identifier:permission-identifier

Example:

If you have:

  • A resource with identifier: product-api
  • A permission with identifier: delete-product

The resulting scope will be: product-api:delete-product

This scope can then be requested in authorization requests and will appear in access tokens, allowing fine-grained access control to your APIs and resources.

The authserver resource is a system-level resource used internally by Goiabada. It has special protections:

  • Its resource identifier cannot be changed (renaming is blocked)
  • It cannot be deleted
  • Its description can be modified
  • New permissions can be added to it
  • Its built-in permission identifiers cannot be renamed or deleted

The built-in permissions under the authserver resource are:

Permission identifierPurpose
userinfoAccess to the /userinfo endpoint
manage-accountSelf-service account management (Account API)
manageFull admin access to all Admin API endpoints
admin-readRead-only access to all Admin API endpoints
manage-usersFull access to user, group, and permission endpoints
manage-clientsFull access to client endpoints
manage-settingsFull access to settings and key endpoints

You can create additional custom permissions on the authserver resource if needed, but the built-in ones listed above are protected.

  1. Define resources - In the admin console, create resources that represent your APIs or protected areas (e.g., product-api, user-service)

  2. Create permissions - For each resource, define the actions users or clients can perform (e.g., read, write, delete)

  3. Assign permissions - Grant these permissions to:

    • Individual users
    • Groups (all members inherit the permissions)
    • Clients (for server-to-server access)
  4. Request scopes - When initiating an authorization request, include the scopes your application needs:

    scope=openid product-api:read product-api:write
  5. Validate access - In your API, check the access token for the required scopes before allowing access to resources