4. Config resource & security info
Last updated
Last updated
What you’ll do: Define your app’s identity, API resources, and access permissions to establish how it securely interacts with Oten Platform. You’ll configure the client credentials (Client ID), define your app’s capabilities and scopes, and link integrations with other apps in the Oten ecosystem.
Client Identity — client credentials for your application.
App Capabilities & Security — your API model (permissions, features, scopes). Optional.
Ecosystem Connections — connect other apps from the Oten platform and select the scopes you grant to each integration.
Why it matters: Properly configuring resource & security ensures your app is authenticated, authorized, and securely connected within the Oten ecosystem. This step protects user data, enforces permissions, and enables safe interoperability between your app and other Oten services or third-party integrations
Steps:
Client identity: Create a client
Open App Management → Configure Resources & Security → Client Identity.
Create a client and choose a client type (see below).
Save. You will receive a Client ID; server‑side apps also receive a Client Secret.
Use this client in your app to run the standard Authorization Code flow (with PKCE when required).
Client types:
Single Page Application (SPA — PKCE)
Use for browser‑based apps running entirely on the client.
Grant: Authorization Code with PKCE. No client secret (public client).
Required: at least one Redirect URI; configure Allowed Logout URL if you support logout.
Security notes: never store tokens in localStorage if you can avoid it; prefer HTTP‑only cookies via a backend for session management, or short‑lived Access Tokens with refresh via a secure channel.
Regular Web Application (server‑side)
Use for apps that render on the server or have a backend that can keep secrets.
Confidential client: you will receive a Client Secret; keep it on the server only.
Grant: Authorization Code (no PKCE required, but PKCE is recommended when available).
Typical flow: browser → authorize → your server exchanges code for tokens → sets session.
Native Application (mobile/desktop — PKCE)
Use for iOS/Android apps or desktop apps.
Grant: Authorization Code with PKCE. No client secret.
Redirect URI: use an app scheme (e.g., myapp://callback) or a loopback URI (e.g., http://127.0.0.1:PORT/callback) as supported by your platform.
Using your client: login, logout, profile:
Step 1 — Define the resource server
The resource server represents your API or backend system in Oten. It becomes the audience that appears in access tokens.
.png)
Fields (as shown in the Add Resource dialog):
Best practice:
Step 2 — Define permissions (API level)
Use permissions to tell Oten which HTTP methods and paths in your API are allowed.
This step covers API permissions created in the UI. If you need to protect screens/routes in your app UI, see Roles.
Fields (Add Permission dialog):
How to add API operations
.png)
Example
Tips and rules
Step 3 — Privileges
Features are bundles of permissions that represent a capability in your product (e.g., “View games”, “Manage orders”). Users don’t assign permissions directly; they get them through Roles that include Features.
.png)
Fields (privilege dialog):
How to create a feature
Examples
Tips and rules
How privilege work with roles
Automated role provisioning
Step 4 — Define scopes (for cross‑app access and consent)
Scopes represent what another application can access on behalf of a user or a client. A scope can map to:
When an external app requests access, the consent screen will present the scopes you expose. On approval, access tokens will include the granted scopes; Oten verifies scopes and routes access only to the APIs covered by those scopes.
Naming tips:
Use Integrate to expand your app by connecting to other applications on the Oten platform and granting them scoped access.
.png)
Steps:
Notes:
Login
Redirect the user to the Authorization Endpoint with response_type=code, your Client ID, Redirect URI, requested scopes, and a code_challenge (PKCE when required).
Receive the authorization code at your Redirect URI.
Exchange the code for tokens at the Token Endpoint (add code_verifier for PKCE).
Logout
Clear the local session and redirect the user to the configured logout endpoint (if your tenant exposes one) with a post‑logout redirect URI that matches the allowed list.
Get profile
Call the UserInfo endpoint (or decode the ID Token) using the Access Token obtained above. Request the appropriate scopes (e.g., openid, profile, email) during login.
App capabilities & security (optional — Oten IAM)
Identifier
Yes
Unique URI/URN for your API. Appears as the aud claim in access tokens.
https://api.example.com, urn:oten:resource:my‑service
Name
Yes
Human‑readable name.
Orders API
Base URL
No
Base address of your API (used for documentation and discovery).
https://api.example.com
Description
No
Short description of what this API does.
Manage orders
Server type
No
Type of backend (REST, GraphQL, gRPC).
REST
Version
No
Semantic version label.
v1
Environment
No
Environment tag.
dev, staging, prod
Allowed issuers
No
Trusted identity issuers. Tokens must come from one of these.
https://auth.example.com
Tags
No
Free‑form labels to help search and group.
api, production, backend
Metadata
No
Additional structured info.
JSON blob
Choose a stable Identifier and do not reuse it across different environments; use one per environment when needed.
Keep Allowed issuers in sync with the identity domain that issues tokens for your app.
Code
Yes
Unique identifier for the permission in your app. Use lowercase, numbers, dot or hyphen; no spaces.
games.read, users-manage
Name
Yes
Human-readable name shown in the console and consent screens.
View games
Type
Yes
Choose API permission (backend).
API
API operations
Yes
One or more operations this permission grants, each as Method + Path. Wildcard * matches subpaths.
GET /api/v1/games, GET /api/v1/games/*
Click Add row, pick the HTTP method (GET, POST, PUT, PATCH, DELETE).
Enter the path exactly as your API exposes it (e.g., /api/v1/games).
Use * to include subroutes (e.g., /api/v1/games/*).
Add multiple rows if the permission should cover more than one operation.
Name: “View games list”
Code: games.read
API operations: GET /api/v1/games (optionally GET /api/v1/games/*). When a request hits those endpoints, Oten checks the caller has games.read.
Keep Code stable; treat it as an internal identifier (avoid renaming after publish).
Code must be unique in your app and use only letters, digits, dot, underscore or hyphen; no spaces.
Prefer least privilege: separate read vs write, admin vs user operations.
Group multiple endpoints under one permission only when they represent the same capability.
Code
Yes
Unique identifier for the feature in your app; use lowercase, numbers, dot or hyphen; no spaces.
games.readonly, orders-manage
Name
Yes
Human‑readable name shown in the console.
Games: Read only
Description
No
Optional explanation to help admins understand the feature.
Read game listings and details
Permissions
Yes
Select one or more previously defined permissions that this feature should grant.
games.read, games.write
Click Add privilege.
Enter name and code; optionally add a description.
Click Add permission and select one or more permissions that represent the capability.
Save.
“Games: Read only” → permissions: games.read
“Games: Manage” → permissions: games.read, games.write
“Orders: Admin” → permissions: orders.read, orders.create, orders.update, orders.delete
Keep features focused on a single capability so admins can compose roles cleanly.
Reuse features across roles; avoid creating near‑duplicate features.
Choose clear names (prefix by domain), e.g., “Games: Read”, “Games: Manage”, “Orders: Refunds”.
Changing a feature changes all roles that include it; prefer adding new features over repurposing existing ones.
In the roles tab, you attach privilege to a role.
Users/groups assigned that role automatically inherit all permissions from the attached Features.
When a developer adds a new privilege, the platform automatically provisions a corresponding default access role. This role is instantly granted to two primary entities: The personal account user (upon account creation) and the Workspace admin (upon application subscription). This mechanism streamlines the onboarding process, allowing them to access the application immediately without requiring subsequent self-permissioning steps.
A set of API operations, or
One or more permissions you defined in Step 2
Use a clear, name spaced format (e.g., games.read, chat.write, reporting.export).
Keep scopes stable and backward‑compatible; add new scopes rather than repurposing existing ones.
Ecosystem connection
Open the Integrate tab and click add integrate app.
Search for the provider application and switch it On.
Under “Select scopes to integrate with this application”, choose the scopes you want to grant.
Save.
Only apps that expose scopes (via their resource server → scopes) will have selectable scopes. Otherwise you will see “No scopes available for this app”.
Turning an app Off revokes future access; existing tokens may continue to work until they expire.
When initiating OAuth with that provider, request the selected scopes. Users/org admins will review and consent to these scopes.
Your app authenticates the user and obtains an access token.
The token carries issuer (iss), audience (aud = your resource server Identifier), scopes, and/or permissions.
When the API is called, Oten IAM checks that:
The token’s issuer is in allowed issuers.
The audience matches your resource server Identifier.
The requested operation is allowed by the token’s scopes/permissions.
Invalid_redirect_uri: ensure your redirect URI exactly matches one of the allowed URIs.
Invalid_grant or PKCE errors: verify code_verifier and code_challenge pairing and that you exchange the code only once.
Mismatched_issuer: add the correct issuer base URL to Allowed issuers on the resource server.
Insufficient_scope: request or grant the scope/feature/permission that covers the API you are calling.
Test the login flow with your chosen client type.
If you registered a resource server, call your API with a token that has the required audience and scopes; confirm Oten allows/denies as expected.
In Integrate, enable a provider app and select scopes; run a consent flow and verify the granted scopes appear in the token and permit only the intended APIs.
In Roles, assign a role to a test user and verify features linked to that role gate functionality correctly.
Continue to “Test your app” or “Publish your app” once authentication and authorization work end‑to‑end.