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
- 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
- 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.
- Based on the context that is provided in the request to
- 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.