Since the same JWT works in Postman but fails from Power Automate, the approach is architecturally correct. The issue is almost certainly one of these:
1. Token expiry timing. The JWT is generated, then by the time the HTTP action fires in Power Automate there may be enough delay that iat/exp claims are outside Oracle's tolerance window.
Oracle Fusion is strict about clock skew. Decode the token Power Automate is actually sending (Compose the Authorization header value and check run history) and verify exp is still in the future when Oracle receives it.
2. Authorization header formatting. Power Automate's HTTP action has a built-in Authentication setting in the action properties. If you're also manually adding Authorization as a header, they can conflict or double-set the header. Set authentication to None in the action properties, and add Authorization: Bearer <token> manually in the Headers section only.
3. Token not being passed correctly. Add a Compose action in the flow that outputs exactly what goes into the Authorization header. Check the run history of that Compose to confirm the token value matches what worked in Postman, including no extra whitespace or line breaks from Base64 encoding.
The architecture (Cloud Function generates JWT, Power Automate HTTP action calls Oracle with Bearer header) is correct per the pattern Microsoft documents for custom JWT auth. The failure is in the execution detail, not the design.
Best regards,
Valantis ✅ If this helped solve your issue, please Accept as Solution so others can find it quickly.
❤️ If it didn’t fully solve it but was still useful, please click “Yes” on “Was this reply helpful?” or leave a Like :).
🏷️ For follow-ups @Valantis.
📝 https://valantisond365.com/ 💼 LinkedIn ▶️ YouTube
