How to intercept M2M token in OpenFGA's API calls ?
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 54
- Forks
- 26
- Avg merge
- 2d 7h
- Merged PRs (30d)
- 9
Description
Description
Sub - Issue with Bearer Token and Store Creation in OpenFGA
I'm currently working with OpenFGA and I have a custom bean that overrides the default OpenFGA bean. The goal is to ensure that a store is created only once. When creating the store, if it doesn't already exist, it should be automatically created, and the store ID should be added to other AuthorizationModel APIs.
However, I'm running into an issue. I keep getting the error message "invalid bearer token." The M2M token is being created successfully, but for some reason, it’s not being properly intercepted when the store is created within the custom bean. This is causing the token to be invalid during the API calls.
As a workaround, I tried switching to direct API calls using the RestClient to call OpenFGA APIs. The RestClient provides an option for requestInterceptor(), but I’m struggling to set the M2M token in the header correctly. Despite my efforts, the token is still not being passed correctly, and I continue to face authentication issues.
Has anyone encountered a similar problem or have any advice on how to intercept and set the M2M token in the header when using the RestClient? Any insights or solutions would be greatly appreciated!
Thanks in advance!
Version of SDK
v0.4.0
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the custom OpenFGA bean and the RestClient requestInterceptor described in the issue, then trace the store-creation and AuthorizationModel API calls. Confirm where the M2M token is created and whether it reaches each request's authorization header; done means the calls authenticate successfully without the invalid bearer token error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, authentication
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100