API Authorization
Technical overview of setting up JWT-based auth for UpGrade endpoints
Technical overview of setting up JWT-based auth for UpGrade endpoints
Optionally, your application can secure endpoint communication by turning on API token-based authentication. This will require requests to pass a signed JWT token that has been encrypted with the application environment's CLIENT_API_SECRET
and CLIENT_API_KEY
(or a verified Google Auth credential has been obtained by via the UpGrade UI's via valid Google-email-based login token exchange).
The UpGrade API has two kinds of endpoint authorization flows that are available:
1. for system-to-system communication, typically via the publicly available client library packages for TypeScript and Java
2. for working with the UI or via direct API calls for all other endpoints.
Client applications will communicate user interactions to UpGrade via the Client SDK endpoints (such as init
, assign
and mark
), typically using a client library package that can help streamline these actions.
To create a signed token to secure communication from the client system -> UpGrade API, the client will need to have knowledge of the UpGrade API CLIENT_API_SECRET
and CLIENT_API_TOKEN
values for that environment. With those details obtained, a valid token can be created and tested via a jwt-signing package such as in the following javascript snippet:
Using direct API call or cURL: Send in header as an API Token Authorization with Authorization
as key and the token as value:
Using TypeScript or Java client library: Pass the signed token in the constructor
Once your client calls are equipping requests with valid tokens, you can enable auth in UpGrade. Client-SDK authorization for environment is toggled via a setting in the upgrade database settings
table
1. Via admin user toggle in an environment.
NOTE: This may not be a safe approach for use in a multi-tenent environment as this is a global setting for all users. This feature may be removed for these reasons in the future.
Directly modify the toCheckAuth
boolean in the settings
table.
All other endpoints are secured using Google-Credential based token-exchange in order to use UpGrade's UI and use other admin-level endpoints.
Setting up Google Auth for your UpGrade instance is a separate discussion.
In summary, the Google Auth servers will have our same CLIENT_API_SECRET
and CLIENT_API_KEY
as above. When a valid gmail user that is known to UpGrade logs in using your UpGrade instance's GOOGLE_CLIENT_ID
, a JWT credential will automatically be passed to all UpGrade requests from the UI.
Once obtained, this token can also be used by a developer for direct API access as a Bearer token.
When your application is correctly receiving user-credential tokens from the GSI process in the UI, you can secure your endpoints by setting AUTH_CHECK
env var to true. When true, only users who are present in ADMIN_USER
in the env will be able to obtain a valid token from Google. All others will receive a 401 error.
2. Send in a POST request to /settings
To test if your application is set up correctly, enable auth using one of the above methods in your environment. , try sending in a valid request to the init
endpoint (no need to have any experiments running). If success, you should see your data. If fail, you should see a 401 error: