Authorization
Table of Contents
Overview
Token Exchange enables your backend to obtain Boosted access tokens for your users without browser redirects or user interaction. This method is designed for backend-to-backend integrations where you embed Boosted features directly in your application.
Authentication Flow:
- User is authenticated in your application
- User requests access to Boosted features
- If it is their first time, perform token exchange with
subset to your client ID to obtain a service account token - Use the management token to create the account hierarchy (Organization → Workspace → User)
- If it is their first time, perform token exchange with
- Your backend creates a signed JWT asserting the user’s identity
- Your backend sends JWT to Boosted’s token endpoint
- Boosted validates JWT signature and returns access tokens
- Your backend uses access tokens to call Boosted APIs on user’s behalf
No user redirects, login screens, or consent flow.
Standards:
- RFC 8693 - OAuth 2.0 Token Exchange
- RFC 7523 - JWT Profile for OAuth 2.0
- RFC 7519 - JSON Web Token (JWT)
What You Need to Provide Us
1. Public Signing Key URL (jwks_uri)
Provide the public URL where your JWKS (JSON Web Key Set) is hosted. We will fetch your public keys from this endpoint to verify signatures.
How to generate and host:
- Generate Keys:
- Convert & Host:
- Convert the public key to JWKS format (JSON).
- Upload the JSON file to a publicly accessible location (e.g., AWS S3, a static site, or a dedicated API endpoint).
Example URL:
https://your-domain.com/.well-known/jwks.json
Expected Response (at the URL above):
What We Will Provide You
1. Client ID
Used for:
- Token exchange request body
- JWT
issclaim (issuer) - JWT
subclaim (for token exchange to use the account-management API)
2. Client Secret
Used for:
- Token exchange request body
3. Token Endpoint
Send your token exchange requests here.
4. Account Management API Endpoints
Create the organizational hierarchy via these endpoints before performing token exchange for users.
5. Audience Value
Include this in the aud claim of your JWT.
6. JWT Requirements
Your JWT must include these standard claims:
7. Available Scopes
You can request specific scopes in your token exchange request. Your partner account will be configured with allowed scopes.
What You Need to Implement
1. Account Setup Flow
The Threads API requires an access token for a user with the thread scope. Before you can generate these tokens, you must set up your accounts using the Account Management API.
Account Hierarchy
The Account Management API uses a three-tier hierarchy:
- Organization: Your top-level entity
- Workspace: Groups of users within an organization
- User: Individual accounts that can access the Threads API
Choosing Your Structure
For most use cases, we recommend starting with a simple structure:
- 1 Organization
- 1 Workspace
- All users in that single workspace
This approach works well when you don’t need to segment users into different groups. If you have more complex requirements (e.g., separating internal production use from end user production use, or isolating different end user groups), contact us for guidance on structuring your hierarchy.
Step 1: Get Service Account Token
Perform token exchange with your client ID as the subject to obtain a management token:
The bash snippets use process substitution <(...) which requires bash. Add #!/bin/bash at the top of your script or run with bash script.sh.
Step 2: Create Organization
Step 3: Create Workspace
Step 4: Create User
2. User Token Exchange
When a user needs Boosted access, create a JWT with their User ID as the subject and exchange it for an access token:
Example Response:
3. Using the Threads API
Use the access token to call Boosted APIs:
4. Complete Integration Example
5. Token Expiration Handling
Access tokens expire after 1 hour. When expired, perform another token exchange:
Token Exchange does not return refresh tokens. When the access token expires, create a new JWT and perform another token exchange.
