I'm exposing an API for external systems to call (e.g. allow other system to automatically fetch/post some data to my app in ODC). I don't want to use Basic Authentication, so thinking of implementing an OAuth 2.0 and building my own Authorization "server" for this.
From my understanding, this is the client credential flow:
- I'll create a ClientID and Secret to share with the external system.
- I'll expose an endpoint (#Token Endpoint) where the external system can request a token using the ClientID and Secret.
- Then use that token to validate the another exposed endpoint (#App Endpoint) where the external system can POST/GET etc.
My question is in ODC, how would you handle this flow? (in O11, you probably would build a module for it)
- Create 1 App for Token Management? With a table that records the current active tokens?
- Then make a Service action to validate the active token? So all other apps that exposes an API uses this same application to handle it.
or
Each application handles their own tokens.
Note:
I read about ODC REST API and creating an API client, but my understanding is that it is for the platform's API (e.g. Users API, Portfolio API, etc.). If that's true, the naming is a bit confusing, I think it should be called "ODC Portal API" or something. If I'm wrong and it is for all custom exposed APIs on apps that we built then maybe I can use that?
Hi @Danpob Pairoj-Boriboon ,
You’re on the right track — implementing a client credentials–style OAuth 2.0 flow is the right approach for system-to-system integrations.
In ODC, since there’s currently no built-in OAuth 2.0 authorization server, the best practice is to centralize token management in a dedicated application, rather than handling tokens separately in each app.
1. Create a dedicated “AuthService” app
Maintain entities for ClientID, hashed Secret, and issued tokens (with expiry, scopes, and status).
Expose a /token endpoint that validates client credentials and issues a token (JWT or GUID) with an expiry time.
Optionally include metadata like expires_in, scope, and token_type for consistency with OAuth standards.
2. Implement centralized validation
Expose a Service Action (e.g., ValidateToken) in the same app that checks token validity and expiry.
Reference this Service Action from other apps that expose APIs, so all token validation logic stays consistent and maintainable.
3. Consumer workflow
External systems call /token using ClientID and Secret to obtain a valid token.
They include this token in the Authorization header (e.g., Bearer ) when calling your other APIs.
Each API first calls ValidateToken before processing the request.
4. Important note about ODC REST APIs You’re correct — the ODC REST APIs (Users, Portfolio, Deployments, etc.) are for managing the ODC platform, not your custom app APIs. They can’t be used as an authorization mechanism for your applications.