# How to inject per-request arbitrary claims (e.g. workstation) into Okta-issued tokens without exposing a public inline-hook endpoint?

**URL:** <https://devforum.okta.com/t/how-to-inject-per-request-arbitrary-claims-e-g-workstation-into-okta-issued-tokens-without-exposing-a-public-inline-hook-endpoint/34537>\
**Category:** OAuth/OIDC\
**Created:** [October 29, 2025, 8:38am UTC](https://devforum.okta.com/t/how-to-inject-per-request-arbitrary-claims-e-g-workstation-into-okta-issued-tokens-without-exposing-a-public-inline-hook-endpoint/34537 "2025-10-29T08:38:26Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![harshilshah456](https://avatars.discourse-cdn.com/v4/letter/h/bc79bd/32.png) [@harshilshah456](https://devforum.okta.com/u/harshilshah456)\
**Post date:** [October 29, 2025, 8:38am UTC](https://devforum.okta.com/t/how-to-inject-per-request-arbitrary-claims-e-g-workstation-into-okta-issued-tokens-without-exposing-a-public-inline-hook-endpoint/34537/1 "2025-10-29T08:38:26Z")

</div>

Hello — we’re implementing an OIDC-based auth flow where our clients (MSAL apps) need to pass _per-request_ contextual values (for example: `workstation`, `session_id`, device fingerprint) and have those values appear as claims in the tokens Okta issues (ID token or access token).

**Important constraints**

- This is an enterprise environment with strict networking: we **cannot** expose a public HTTPS endpoint that Okta would call (so Token Inline Hooks that require Okta → our service callbacks are effectively blocked).

- Okta acts as the OIDC IdP and federate authentication to ADFS for users.

- We control the client code (MSAL), ADFS, and backend services, but cannot open inbound tunnels from Okta to our network.

**What we want**

- Per-request (dynamic) values provided by the client at the time of authentication — e.g., `workstation=DESKTOP-007` — to be available as claims inside the Okta-issued token.

- Prefer a solution that requires minimal infra changes and no public endpoints.

---

<div class="post-metadata">

**Author:** ![andrea](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/andrea/32/2172_2.png) [@andrea](https://devforum.okta.com/u/andrea)\
**Post date:** [October 29, 2025, 3:29pm UTC](https://devforum.okta.com/t/how-to-inject-per-request-arbitrary-claims-e-g-workstation-into-okta-issued-tokens-without-exposing-a-public-inline-hook-endpoint/34537/2 "2025-10-29T15:29:42Z")

</div>

The only solution I know for this is Inline Hooks, which, as you mentioned, requires that the hook endpoint be publicly accessible.

If you’re not able/comfortable hosting a public endpoint for this in your own infrastructure, what about creating a Workflow as the hook endpoint (as described [here](https://iamse.blog/2023/01/30/inline-hooks-with-okta-workflows/))?

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/oktadev/original/1X/589c4c5f80de422d01f47cee7185a7fb8227835c.png) [@system](https://devforum.okta.com/u/system)\
**Post date:** [November 28, 2025, 3:29pm UTC](https://devforum.okta.com/t/how-to-inject-per-request-arbitrary-claims-e-g-workstation-into-okta-issued-tokens-without-exposing-a-public-inline-hook-endpoint/34537/3 "2025-11-28T15:29:48Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.