Remarques sur l'écriture des stratégies d'applications natives
Les stratégies d'applications natives appliquent les règles de premier facteur avant l'authentification de l'utilisateur. Après l'authentification de l'utilisateur, les règles d'authentification multi-facteur classiques peuvent être appliquées.
Ecriture des règles de premier facteur
- Refuser l'accès en fonction du contexte présenté
- Par exemple, une règle de géolocalisation simple qui requiert l'accès uniquement à partir d'un certain emplacement.
- Modifier la façon dont un utilisateur doit effectuer l'authentification de premier facteur
- Par exemple, si un utilisateur ne se trouve pas sur le réseau d'entreprise (une règle IP), FIDO2 doit être utilisé comme alternative à l'authentification par mot de passe.
Les règles de premier facteur ne sont utilisées que dans les flux où le type d'octroi policyauth est utilisé. Si des octrois password ou jwtBearer non sollicités sont utilisés, les règles à deux facteurs sont utilisées uniquement après la validation du contexte authentifié initial.
Ecriture des conditions de premier facteur
- Conditions de contexte
- Basées sur le contexte fourni dans la demande à destination de
/token - Peuvent être utilisées pour modifier la stratégie en fonction du type de flux OAuth exécuté.
- Basées sur le contexte fourni dans la demande à destination de
- Conditions IP
- Conditions d'emplacement
Ecriture des règles à deux facteurs
La création de règles à deux facteurs reste la même pour les types d'octroi gérés par API. Cependant, elle diffère d'un flux de connexion unique de navigateur classique. Dans le flux classique, le contexte auquel s'applique cette stratégie d'accès (à savoir la session) se limite à la session du navigateur. Dans un type d'octroi géré par API, il se limite à la durée de vie de l'intégralité de l'octroi OAuth, ce qui peut être une échelle de temps beaucoup plus longue.