The rule that allows application sign-ins (federation.authorize)

Every application sign-in (OIDC services, SAML applications and Microsoft 365) evaluates the action federation.authorize. Without a rule that allows it, every one is refused.

Which resource identifies each application?

Example rule

This rule allows three applications to people who sign in with a passkey or phone approval. It goes in the rules list of the revision document:

{
  "id": "allow-applications",
  "priority": 100,
  "order": 0,
  "effect": { "decision": "allow", "reason_code": "rule_allowed" },
  "all_of": [
    { "type": "action_any", "values": ["federation.authorize"] },
    { "type": "resource_exact_any", "values": ["hr-portal", "saml:<application-id>", "wsfed:<federation-id>"] },
    { "type": "auth_method_any", "values": ["passkey", "device_approval"] }
  ]
}

Notes

• resource_exact_any takes exact values, with no prefixes or wildcards. A rule without a resource condition applies to every application.
• Phone approval: it is accepted for an application only when a rule allows device_approval for it. Otherwise the phone shows «The organization's access policy does not allow approving sign-ins to this service on the phone.» and the page points to the passkey.
• Phishing-resistant assurance: for a sensitive application (cloud administration, payroll), create a rule with only "passkey" in auth_method_any and add { "type": "auth_user_verified", "required": true }.
• The «New OIDC portal sign-in rule» assistant creates rules that require a Presence device; in an organization without those devices, write the rule in the document as in the example.

How do I test?

Use «Test decision» with a passkey context and a phone-approval context before activating. See Simulate a policy.

Where do I see refusals?

Under «Operate» › «Audit»: refused OIDC sign-ins appear as oidc.authorization.standard_denied.