Application request parameters
An application can supply values for claim transforms, such as a profile ID or a list of departments. Configure Allowed request parameters on its application registration to make selected values available as _local:params:{name} claims.
Configure parameters
Enable Show advanced and configure Allowed request parameters on the application registration.
Add each allowed parameter name. The list is empty by default. Names are stored in lowercase; use underscores between words, for example profile_id.
FoxIDs splits parameter values on spaces automatically. A value without spaces produces one claim; a space-separated list produces one claim per element. Values retain their case. For example:
profile_id=16b66fb6-9f88-4a10-b489-8e54f48f76a4&departments=Sales%20Support
With profile_id and departments configured as allowed parameter names, transforms receive:
_local:params:profile_id = 16b66fb6-9f88-4a10-b489-8e54f48f76a4
_local:params:departments = Sales
_local:params:departments = Support
Leading, trailing and repeated spaces are ignored. Quotes have no special meaning. Send the list in one parameter occurrence.
Supported requests
| Request | Parameter source | Available in claim transforms |
|---|---|---|
| OpenID Connect authorisation | Query string | Authentication method and application |
| SAML 2.0 authentication | Query string, or form fields with HTTP-POST | Authentication method and application |
| WS-Federation passive sign-in | Query string, or form fields with HTTP-POST | Authentication method and application |
| OAuth 2.0 / OpenID Connect client credentials | Token request form | Application |
| OAuth 2.0 / OpenID Connect token exchange | Token request form | Selected authentication method, when validating an external subject token, and application |
Authorization-code redemption and refresh-token requests use the existing grant claims; additional request parameters are not made available to transforms.
For SAML, send the parameters alongside the protocol message. With HTTP-Redirect, add them after creating the signed redirect URL so the SAML message and signature remain intact. These additional parameters are outside the signed SAML message.
Limits
| Setting | Limit |
|---|---|
| Configured parameter names | 10 |
| Name length | 30 ASCII letters, digits, underscores or hyphens |
| Received values across all parameters | 10 |
| Each decoded value | 500 characters |
| All decoded values combined | 1,000 characters |
Parameter names match without regard to case. Unconfigured names are ignored. Configured parameters must occur once and contain non-blank values. A repeated parameter, including the same name in both query and form, or a value exceeding the limits causes the request to be rejected with a protocol error. List separators do not count towards the combined value length.
Use parameters in transforms
During browser login, parameters are available from the authentication method's first-level claim transforms. They remain available in subsequent transform sets, including Extended UI and application transforms, throughout that login flow. Each set receives the original accepted values as local claims.
Use a Map transform to copy a value to an ordinary claim for output, or to an _internal: claim for later processing. To retain an authorised selection for later application logins, map it to an _session: claim in the authentication method. A subsequent login can use its supplied parameter or, when absent, the saved session claim. See local, internal and session claims.
Parameters are input supplied by the caller. Before using a profile ID for impersonation or another privileged operation, check the authenticated user's permissions and the target user's eligibility. A supplied ID identifies a requested target; it does not authorise access. Avoid sending secrets in query parameters.