Considerations for writing native application policies

Native application policies apply first factor rules before the user authenticates. After user authentication, traditional MFA rules can be applied.

Writing first factor rules

First factor rules are driven by the context information that is presented by a client before any user or subject is known. The rules can trigger the following actions.
Deny access based on presented context
For example, a simple geolocation rule that requires access only from a certain location.
Change how a user is to perform first factor authentication
For example, if a user is not on the corporate network (An IP rule), FIDO2 must be used as an alternative to password authentication.

First factor rules are only used in flows where the policyauth grant type is being used. If password or unsolicited jwtBearer grants are being used, second factor rules are used only after the initial authenticated context is validated.

Writing first factor conditions

Because no user or subject is present, the number of conditions that can be included in a rule is reduced. Currently, these conditions are supported.
  • Context conditions
    • Based on the context that is provided in the request to /token
    • Can be used to alter policy based on the type of OAuth flow that is being performed.
  • IP Conditions
  • Location conditions

Writing second factor rules

Authoring of second factor rules remains the same for API-driven grant types. However, it differs from a traditional browser SSO flow. In the traditional flow, the context to which that access policy is applied (that is, the session) is scoped to the session of the browser. In an API-driven grant type, it is scoped to the lifetime of the entire OAuth grant, which can be a much larger time scale.